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für die konzeptionelle Gestaltung Serviceorientierter Berichtsprozesse integrieren 
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Geleitwort 


Trotz seiner Bedeutung als Instrument zur Unternehmenssteuerung und der 
Existenz vieler Beiträge, die sich mit der Gestaltung und dem Betrieb von In- 
formationssystemen (IS) auseinandersetzen, sind das interne und externe IS- 
gestützte Reporting nach wie vor mit diversen Problemfeldern konfrontiert, die 
ein aussagekräftiges und verlässliches Berichtswesen beeinträchtigen. Die Stö- 
rungsursachen treten infolge einer mangelnden Integration der zum Einsatz 
kommenden Berichtsdaten, -funktionen, -prozesse und -systeme auf. Aus der 
Perspektive der Wirtschaftsinformatik interessieren in diesem Zusammenhang 
neben den Einsatzmöglichkeiten innovativer und leistungsfähiger Informations- 
technik (IT) auch die Gestaltbarkeit und Umsetzbarkeit geeigneter Prozesse zur 
Unterstützung der Berichtszwecke. Fragestellungen, die sich mit dem gezielten 
Einsatz von IT zur Informationsversorgung von Entscheidungsträgern sowie zur 
Unterstützung von Geschäftsprozessen beschäftigen, sind eine zentrale Säule in 
der Forschung des Lehrstuhls für Wirtschaftsinformatik an der Ruhr-Universität 
Bochum. Eine Reihe von wissenschaftlichen Beiträgen wurde zu diesem The- 
mengebiet in den vergangenen Jahren veröffentlicht. 

Die Herausforderung, Entscheidungsträger auf allen Hierarchieebenen einer 
Unternehmungsorganisation mit „den richtigen Informationen zum richtigen 
Zeitpunkt in der richtigen Form“ zu versorgen, legt nahe, die effiziente und ef- 
fektive Verarbeitung der Berichtsinformationen nicht nur aus der Perspektive 
der Prozessorientierung zu betrachten. Bei der berichtsempfängerorientierten 
Erstellung, Ablage und Diffusion der Reports spielt auch zunehmend der 
Dienst- bzw. Servicegedanke eine wichtige Rolle. Damit sich Berichtsinforma- 
tionen mit Hilfe derartiger „Berichtsservices“ zu einem Serviceorientierten Be- 
richtsprozess zusammenfügen lassen, müssen die entsprechenden Dienste kon- 
zeptionell gestaltet und der resultierende Berichtsprozess in einem Architektur- 
modell eingebettet werden. 

Innovative Konzepte, die aus der Perspektive der Wirtschaftsinformatik zur 
Unterstützung Serviceorientierter Berichtsprozesse in Frage kommen, werden 
aktuell unter den Begriffen Serviceorientierte Architektur (SOA) sowie Exten- 
sible Business Reporting Language (XBRL) diskutiert. Herrn Pastwa gelingt es 
in der vorliegenden Dissertationsschrift in ausgezeichneter Form, sowohl SOA 
als auch XBRL, die bis auf wenige Publikationen bisher isoliert voneinander 
betrachtet wurden, zu einem Architekturkonzept und Vorgehensmodell zur kon- 
zeptionellen Gestaltung Serviceorientierter Berichtsprozesse zu integrieren. 


Alexander Pastwa - 978-3-631-75488-7 
Downloaded from PubFactory at 01/11/2019 04:20:29AM 
via free access 


VII 


Der Autor leistet mit seiner Arbeit einen wesentlichen Fortschritt zur Lösung 
des gegebenen Problems. Ich wünsche dem vorliegenden Buch eine gute Auf- 
nahme in die weitere wissenschaftliche Diskussion, die auch im betrieblichen 
Rechnungswesen immer intensiver geführt wird. 


Bochum, im Mai 2010 Roland Gabriel 
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Einleitung | 


1 Einleitung 


Abschnitt 1.1 führt in die Problemstellung und die Motivation der Arbeit ein. 
Daraufhin werden in Abschnitt 1.2 die Ziele der Arbeit sowie der Gang der Un- 
tersuchung vorgestellt. 


1.1 Problemstellung und Motivation der Arbeit 


Das betriebliche Berichtswesen bzw. das Unternehmensreporting gilt heute als 
wichtiges Instrument zur Dokumentation von Ereignissen, zur Auslösung von 
Aktivitäten sowie zur Vorbereitung und Kontrolle von Entscheidungen. Die ef- 
fiziente und effektive Verarbeitung von Geschäfts- und Finanzinformationen 
hängt nicht nur von der Leistungsfähigkeit der eingesetzten Informationstechnik 
(IT) ab. Neben dem Einsatz IT-gestützter Berichtssysteme liegt ein weiterer 
wichtiger Faktor für ein zuverlässiges Reporting in der Gestaltbarkeit und dem 
erfolgreichen Betrieb geeigneter Berichtsprozesse. Die Kernprozesse innerhalb 
eines Berichtsprozesses umfassen die Aufnahme der in den Berichten bzw. Re- 
ports enthaltenen Informationen, die Produktion der Berichte, die Weiterleitung 
der Reports an den jeweiligen Berichtsempfänger(-kreis) und die Aufnahme der 
Berichte. 

Trotz seiner Bedeutung als Instrument zur Unternehmenssteuerung und der 
Existenz vieler Arbeiten, die sich mit der Gestaltung und dem Betrieb IT- 
gestützter Berichtsprozesse auseinandersetzen, ist das Unternehmensreporting 
nach wie vor mit einer Reihe von Problemfeldern konfrontiert, die eine effekti- 
ve und effiziente Ausführung der Berichtsprozesse beeinträchtigen. Während 
die Effektivität des betrieblichen Berichtswesens durch eine mangelnde Emp- 
fängerorientierung, eine geringe Informationsaktualität sowie eine unzureichen- 
de semantische Verarbeitung der berichteten Informationen gefährdet ist, erge- 
ben sich Ineffizienzen infolge technisch- und personenbedingter Störungen. Im 
Ergebnis ist zu konstatieren, dass die Störungsursachen Folge einer mangelnden 
Integration der zum Einsatz kommenden Berichtsdaten, -funktionen, -prozesse 
und -anwendungen sind. 

Einen Ausweg zur Reduzierung dieser Störungsursachen bietet der derzeit in- 
tensiv diskutierte Ansatz einer „Serviceorientierten Architektur“ (SOA), die 
auch als „Dienstorientierte Architektur‘ bzw. „Service Oriented Architecture“ 
bezeichnet wird. SOA beschäftigt sich mit der Frage, auf welche Weise Anwen- 
dungssysteme gestaltet, integriert und wirtschaftlich betrieben werden sollen. 
Aus der Perspektive der Wirtschaftsinformatik richtet sich die Erwartungshal- 
tung an SOA auf die Unterstützung einer integrierten Informationsverarbeitung 
mit dem Ziel, eine stärkere Flexibilität und/oder Automatisierung der Ge- 
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2 Ziel und Gang der Untersuchung 


schäftsprozesse durch den Einsatz wiederverwendbarer (Software-)Services zu 
erzielen. In den aktuellen Beiträgen, die sich mit dem Themenfeld SOA ausei- 
nandersetzen, erfolgt insbesondere eine Diskussion der zum Einsatz kommen- 
den Prinzipien, die sich für die Gestaltung Serviceorientierter Anwendungen 
nutzen lassen. 


1.2 Ziel und Gang der Untersuchung 


Obwohl in den vergangenen Jahren viele Beiträge zum Konzept einer SOA ent- 
standen sind, ist festzustellen, dass die Grundlagenarbeit noch nicht abgeschlos- 
sen ist. Aus einer methodischen Perspektive betrachtet, liegt, neben der Not- 
wendigkeit, ein einheitliches Begriffsverständnis zu etablieren, ein wichtiges 
Forschungsfeld darin, eine geeignete Methodik für die Gestaltung einer SOA im 
Allgemeinen sowie zur Bereitstellung geeigneter Services zur Integration von 
Produktion und Dienstleistung im Besonderen zu entwickeln und einzusetzen.! 
In diesem Zusammenhang sind geeignete Vorgehensweisen zur Spezifizierung 
sowie Verknüpfung von Diensten zu erarbeiten.2 Ein weiteres wichtiges For- 
schungsfeld richtet sich auf die Definition einer geeigneten SOA-Referenz- 
architektur,3 die den strukturellen Bezugsrahmen zur Gestaltung Serviceorien- 
tierter Anwendungen liefert. 

Damit sich Berichtsinformationen mit Hilfe von Berichtsservices entlang ei- 
ner Prozesskette verarbeiten lassen, ist es erforderlich, dass die entsprechenden 
Berichtsprozesse modelliert und die zum Einsatz kommenden Services konzep- 
tionell gestaltet werden. Derartige Services werden im Folgenden als Berichts- 
services bezeichnet, während für einen Berichtsprozess, der mit Hilfe verknüpf- 
ter Services ausgeführt wird, der Terminus Serviceorientierter Berichtsprozess 
(SOBP) verwendet wird. Die konzeptionelle Gestaltung der in einem SOBP 
zum Einsatz kommenden Berichtsservices besitzt eine Bedeutung, da nur wie- 
derverwendbare Services einen Mehrwert für die SOA-betreibende Unterneh- 
mung schaffen. Da SOA u. a. das Ziel verfolgt, bei der Ausführung eines Pro- 
zesses Services zu nutzen, die von unternehmungsexternen Anbietern zur Ver- 
fügung gestellt werden, besitzt die Anforderung, wiederverwendbare Services 
zu konzipieren, eine umso wichtigere Bedeutung. 

Vor dem Hintergrund des Untersuchungsgegenstands dieser Arbeit wird die 
Frage erörtert, wie sich Serviceorientierte Konzepte für die effiziente und effek- 
tive Verarbeitung von Geschäfts- und Finanzinformationen nutzen lassen, um 
die im Zusammenhang mit der Ausführung von Berichtsprozessen auftretenden 
Problemfelder zu reduzieren. Damit wird der Versuch unternommen, ein be- 


l Vgl. Höß et al. (2007), S. 46; Beverungen/Knackstedt/Müller (2008), S. 221. 
2 Vgl. Eymann/Winter (2008), S. 70. 


3 Vgl. Eymann/Winter (2008), S. 70. 
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triebswirtschaftliches Anwendungsfeld mit einem in der Wissenschaft aktuell 
diskutierten Architekturkonzept zu verbinden. 

Mit Blick auf den Untersuchungsgegenstand dieser Arbeit, der die konzepti- 
onelle Gestaltung von Berichtsservices fokussiert, ist zu bemerken, dass auf 
Aspekte, die die technische Umsetzung eines SOBP betreffen, nicht eingegan- 
gen wird. Die Eingrenzung auf die konzeptionelle Gestaltung von Berichtspro- 
zessen erfolgt vor dem Hintergrund, dass die Implementierung von Services 
derzeit keinen Forschungsschwerpunkt bei der Entwicklung Serviceorientierter 
Anwendungen darstellt. Da es in den vergangenen Jahren gelungen ist, Stan- 
dards sowie Software-Werkzeuge zur Realisierung Serviceorientierter Prozesse 
zu entwickeln, die sich in der Industrie etabliert haben, wird in dieser Arbeit auf 
die Auseinandersetzung mit diesem Aspekt verzichtet. Stattdessen ist in der 
wissenschaftlichen Auseinandersetzung mit SOA nach wie vor das Defizit zu 
konstatieren, dass eine methodische Herangehensweise zum Aufbau einer SOA 
fehlt. 

Abbildung 1 stellt den Gang der Untersuchung auf Hauptkapitelebene dar. 
Das Ziel des Kapitels 2 liegt darin, unter Einbezug aktueller Erkenntnisse, eine 
Zustandsbeschreibung der Prozessunterstützung im betrieblichen Berichtswesen 
zu präsentieren. Der Fokus liegt zum einen auf der Erarbeitung begrifflicher, 
konzeptioneller und informationstechnischer Grundlagen des Berichtswesens. 
Im Mittelpunkt stehen dabei die Kernprozesse des Berichtswesens. Zum ande- 
ren werden in diesem Kapitel Problemfelder thematisiert, mit denen das Be- 
richtswesen aktuell konfrontiert ist. Die Problemfelder betreffen sowohl die Ef- 
fektivität als auch die Effizienz der Informationsverarbeitung und lassen sich 
aus der Perspektive der Semiotik betrachten. 

Während heute in vielen Unternehmungen Ausprägungen von Business Intel- 
ligence-Systemen zur Unterstützung von Berichtsprozessen genutzt werden, 
steht mit dem Konzept einer SOA ein Ansatz zur Verfügung, der sich ebenfalls 
für die Zwecke des Reportings nutzen lässt. Der derzeitige Erkenntnisstand um 
SOA ist durch eine Vielzahl von Vorschlägen gekennzeichnet, die darauf fo- 
kussieren, den Gegenstandsbereich einer SOA zu definieren und Nutzungsmög- 
lichkeiten dieses Konzepts aufzuzeigen. Das Ziel des Kapitels 3 liegt darin, 
ausgehend von aktuell zu beobachtenden Problemfeldern im IT-Betrieb und vier 
verschiedenen Auslegungen, die sich in den Beiträgen zum SOA-Konzept iden- 
tifizieren lassen, ein integriertes SOA-Verständnis zu präsentieren. Auch wenn 
die Auslegungen verschiedene Facetten einer SOA betonen, zeichnen sie sich 
durch die Gemeinsamkeit aus, dass die Serviceorientierung den Leitgedanken 
einer SOA darstellt. Daher wird im Folgenden auch die Frage erörtert, welche 
grundlegenden Eigenschaften und Gestaltungsprinzipien einen Service aus- 
zeichnen. Mit den Web Services wird daraufhin eine Technologie vorgestellt, 
die zur Implementierung von Services zum Einsatz kommen kann. 
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Abbildung 1: Grobgliederung der Untersuchung 


Gegenstand des Kapitels 4 ist die Darstellung eines Architekturmodells, das 
sich für die Gestaltung Serviceorientierter Berichtsprozesse nutzen lässt. Zu- 
nächst wird hierzu der Begriff „Serviceorientierter Berichtsprozess (SOBP)“ 
eingeführt. Um eine SOBP auf Basis einer SOA zu entwickeln, ist es erforder- 
lich, ein Architekturmodell aufzustellen, das der Entwicklung und Realisierung 
einer derartigen Anwendung zugrunde liegen soll. Die Herausforderung, ein ge- 
eignetes Architekturmodell zur Gestaltung eines SOBP zu entwerfen, besitzt ei- 
ne große Bedeutung, da ein SOBP einen von vielen zu unterstützenden Prozes- 
sen darstellt, die sich auf Basis einer SOA automatisieren und/oder flexibilisie- 
ren lassen. Vor diesem Hintergrund sind Überlegungen zum architektonischen 
Aufbau einer SOA auch grundsätzlicher Art und unabhängig von der zu unter- 
stützenden prozessorientierten Anwendung anzustellen. Als Ergebnis wird ein 
SOA-Ebenenmodell präsentiert, das zur Gestaltung und Ausführung Serviceori- 
entierter Prozesse mehrheitlich in der Literatur favorisiert wird. 

Die weiteren Ausführungen dieses Kapitels widmen sich der Frage, welche 
Erweiterungen am bestehenden SOA-Architekturmodell vorzunehmen sind, um 
die Informationsverarbeitungsprozesse im betrieblichen Berichtswesen durch 
die Ausführung von SOBP zu verbessern. Als Erweiterung des SOA- 
Ebenenmodells wird mit der Extensible Business Reporting Language (XBRL) 
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ein Standard auf Basis der Extensible Markup Language (XML) vorgestellt und 
in das Architekturmodell integriert, der das Potenzial besitzt, unter semanti- 
schen Gesichtspunkten eine korrekte Verarbeitung der Geschäfts- und Finanzin- 
formationen in einer SOA zu gewährleisten. 

Nachdem in Kapitel 4 ein Architekturmodell für SOBP präsentiert wurde, 
stellt Kapitel 5 eine methodische Vorgehensweise vor, die zur konzeptionellen 
Gestaltung Serviceorientierter Berichtsprozesse zielführend ist. In diesem Zu- 
sammenhang ist festzuhalten, dass sich generell für die methodische Entwick- 
lung von Services, die in einer SOA genutzt werden sollen, bisher keine einheit- 
liche Vorgehensweise durchsetzen konnte.* Im ersten Teil dieses Kapitels wer- 
den zunächst bestehende Vorgehensstrategien, die im Zusammenhang mit der 
Einführung oder Entwicklung Serviceorientierter Anwendungen diskutiert wer- 
den, hinsichtlich ihrer Eignung untersucht, für die konzeptionelle Gestaltung 
von SOBP eingesetzt zu werden. Darauf aufbauend wird im zweiten Teil detail- 
liert ein Ansatz präsentiert, der sich zur konzeptionellen Gestaltung von SOBP 
nutzen lässt. 


4 Vgl. Beverungen/Knackstedt/Müller (2008), S. 222. 
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2 Prozessunterstützung im betrieblichen Berichtswesen 


Dass das betriebliche Berichtswesen ein wichtiges Instrument zur Unterstützung 
der Ereignisdokumentation, Planung, Steuerung und Kontrolle von Unterneh- 
mungen darstellt,5 ist eine Einschätzung, die in der betriebswirtschaftlichen Li- 
teratur geteilt wird.6 Die Notwendigkeit, aussagekräftige und verlässliche Be- 
richte zu produzieren, gewinnt an Bedeutung, da die Shareholder und Stakehol- 
der einer Unternehmung steigende Informationsanforderungen artikulieren.’ Als 
Zugangsmedium und originäre Informationsquelle ist insbesondere das Internet 
in den Vordergrund gerückt. Mit Blick auf die wachsende Bedeutung internati- 
onaler Kapitalmärkte für die Eigenkapitalbeschaffung wird gefordert, das Be- 
richtswesen stärker am Informationsbedarf der Investoren auszurichten.? 

Aus der Perspektive der Wirtschaftsinformatik als interdisziplinäre For- 
schungsdisziplin zwischen der Betriebswirtschaftslehre und der Informatik,!° 
die sich mit der Gestaltung von Anwendungs- und Entscheidungsunterstüt- 
zungssystemen befasst,!! interessiert die Frage, durch welche geeigneten fachli- 
chen Konzepte und informationstechnischen Lösungen sich die Verarbeitung 
der von einer Unternehmung berichteten sowie zu berichtenden Informationen 
verbessern lässt.!2 In einem allgemeinen Verständnis umfasst die Informations- 


5 Die in der Literatur stattfindende Diskussion um die Begriffe Unternehmen und Unter- 
nehmung wird in dieser Arbeit nicht vertieft. Mit Blick auf die in der Literatur gewählte 
Terminologie werden beide Begriffe in den folgenden Ausführungen synonym verwen- 
det. Zur Diskussion dieser Termini vgl. Kuhn (1990), S. 1. 

6 Vgl. dazu Becker/Köster/Sandmann (2006), S. 501; Blohm (1980), S. 317; Göpfert 
(2002), S. 147; Horvath (2006), S. 584. Da die Ausführungen dieser Arbeit sich aus- 
schließlich auf das Berichtswesen von und innerhalb von Unternehmungen fokussieren, 
wird im Text zur Vermeidung einer sprachlichen Monotonie gelegentlich auf das Adjek- 
tiv „betriebliches‘ verzichtet. 

7 Vgl. Gluchowski/Kemper (2006), S. 18. Zum Stakeholder- und Shareholderbegriff vgl. 
Abschnitt 2.1.2. 

8 Vgl. Mertens (1999), S. 409; Lymer (1999), S. 289; Xiao/Jones/Lymer (2002), S. 245; 
Wagenhofer (2003), S. 262. Zu den Vorteilen und Problembereichen der Internetpublizi- 
tät vgl. Schruff/Kayser (2002), S. 353ff. 

9 Vgl. Nutz/Strauß (2002), S. 447. RIDDER/BOMMER weisen in diesem Zusammenhang 
darauf hin, dass die Finanzierungsfähigkeit einer Unternehmung zu geringen Kapital- 
kosten maßgeblich von der Zufriedenheit der Kapitalmarktteilnehmer abhängt. Vgl. 
Ridder/Bommer (2006), S. 615. 

10 Zum Gegenstandsbereich der Wirtschaftsinformatik vgl. Hansen/Neumann (2005), 
S. 101ff. 

II Vgl. Buhl (2008), S. 433; Strangmeier (2008), S. 448. 

I2 Dass die Verbesserung des Berichtswesens eine Herausforderung für die Wirtschaftsin- 


formatik darstellt, wird deutlich bei Becker/Seidel/Janiesch (2008), S. 229. 
Alexander Pastwa - 978-3-631-75488-7 


Downloaded from PubFactory at 01/11/2019 04:20:29AM 
via free access 


8 Terminologi sche und konzeptionelle Grundlagen zum IT-gestützten Berichtswesen 


verarbeitung alle Aktivitäten, die die zweckbezogene Informationsgewinnung 
und -verwendung sowie die Informationstransformation zum Gegenstand ha- 
ben.!3 Werden Informationen maschinell transformiert, so ist dieser Vorgang als 
Datenverarbeitung zu bezeichnen.!* Grundsätzlich lassen sich im betrieblichen 
Berichtswesen jegliche Arten von Informationen verarbeiten, die innerhalb ei- 
ner Unternehmung anfallen. Die folgenden Ausführungen fokussieren dabei die 
Verarbeitung von Geschäfts- und Finanzinformationen. 

Die effiziente und effektive Verarbeitung derartiger Informationen besitzt in- 
sofern eine Relevanz für eine berichtende oder berichtsempfangende Unterneh- 
mung,!5 als einmal produzierte Inhalte — beispielsweise in Form eines Jahresab- 
schlusses — zwischen verschiedenen Berichtsempfängern ausgetauscht und von 
diesen (weiter) verarbeitet werden können oder miissen.!© In Anlehnung an den 
Supply Chain-Gedanken wird die sich daraus ergebende Berichtslieferkette 
auch als Business Supply Chain, Business Reporting Supply Chain, Corporate 
Reporting Supply Chain, eReporting Supply Chain oder als Financial Supply 
Chain bezeichnet.!? Die bei der Verarbeitung der Informationen anfallenden 
Aufgaben umfassen die Interpretation, Aufbereitung, (Re-)Formatierung, Ein- 


13 Mit Blick auf die Begriffsauslegung von GABRIEL/BEIER lässt sich diese Abgrenzung als 
Informationsverarbeitung i. w. S. auffassen. Vgl. Gabriel/Beier (2003), S. 34f. 

14 Vgl. Gabriel/Beier (2003), S. 35. Daten und Informationen lassen sich mit Hilfe der Se- 
miotik unterscheiden. Die Semiotik beschäftigt sich als allgemeine Sprach- und Zei- 
chentheorie mit der syntaktischen, semantischen und pragmatischen Ebene von sprach- 
lichen und nicht-sprachlichen Zeichensystemen. Während sich die Syntaktik mit den 
Regeln zur Verknüpfung von Zeichen befasst, beschäftigt sich die Semantik mit der in- 
haltlichen Bedeutung der Zeichen. Gegenstand der Semantik sind die Beziehungen zwi- 
schen den Zeichen und dem bezeichneten realen Objekt. Die Pragmatik fokussiert die 
Zweckorientierung von Informationen. Zu den Grundlagen der Semiotik vgl. Gabriel/ 
Beier (2003), S. 29ff. Daten bilden z. B. in Form einer Dezimalzahl, die aus den Ziffern 
„6“, „3“ und „9“ sowie dem Sonderzeichen ,,,“ entsprechend der syntaktischen Regeln 
zusammengesetzt ist, einzelne objektive Fakten zu Vorgängen oder Ereignissen ab. In- 
dem eine Beziehung zur Realität hergestellt wird und die Daten in einen Kontext einge- 
ordnet werden, entstehen aus Daten Informationen im Sinne der semantischen Ebene der 
Semiotik. Aus der Dezimalzahl 6,39 entsteht somit eine Kennzahl, wenn eine sachliche 
Beschreibung durch eine Dimensionsangabe wie z. B. Return on Investment (ROT) hin- 
zugefügt wird. 

15 Zum Effizienz- und Effektivitätsbegriff vgl. Abschnitt 2.3. Der Begriff der Gestaltung 
steht in diesem Zusammenhang für den gesamten Prozess der systematischen Entwick- 
lung eines IS, wobei sich als Teilschritte dieses Prozesses die Phase der Planung, der 
Entwicklung, der Integration in eine Anwendungsumgebung sowie die Phase des Ein- 
satzes identifizieren lassen. Vgl. Gluchowski/Gabriel/Chamoni (1997), S. 63. 

16 Vgl. dazu Pandrangi (2003). 

17 Vgl. Farewell (2006), S. 161; a a S. 179; Brown Willis 


(2003), S. 70; Meyer-Pries/Gröner (2002) 5 . 53; Baars (2005), S. 194. 
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gabe und Validierung der berichteten Informationen.!8 Ferner kommt bei der 
Erstellung, Weitergabe und Aufnahme der Berichte eine Reihe von Personen, 
Informationssystemen (IS) und Daten- bzw. Dateiformate zum Einsatz, die eine 
schnelle und verlässliche Verarbeitung der Berichte erschweren.!9 Als Berichte 
bzw. Reports kommen sämtliche Dokumente in Frage, in denen betriebswirt- 
schaftliche Sachverhalte aufbereitet, bereinigt und miteinander verknüpft sind 
mit dem Ziel, die unternehmungsinternen und/oder -externen Adressaten mit re- 
levanten und korrekten Informationen zu versorgen und sie damit bei der Erfül- 
lung ihrer Aufgaben zu unterstützen.20 Die Berichte verarbeiten Informationen, 
die in den betrieblichen IS vorgehalten werden.?! 

In diesem Zusammenhang fordert GÖPFERT, beim betrieblichen Berichtswe- 
sen logistische Konzepte einzubeziehen mit dem Ziel, die effektive und effi- 
ziente Informationsversorgung der unternehmungsinternen und -externen Be- 
richtsempfänger zu unterstiitzen.22 Losgelöst von der Frage, ob die Berichts- 
empfänger sich innerhalb oder außerhalb einer berichtenden Unternehmung be- 
finden, hat die Forderung, logistische Konzepte für die Zwecke des betriebli- 
chen Berichtswesens zu berücksichtigen, zur Konsequenz, den Fokus nicht nur 
auf die bloße informationstechnische Unterstützung der anfallenden Aufgaben 
bei der Verarbeitung der berichteten sowie zu berichtenden Informationen aus- 
zurichten. Gleichzeitig ist die bessere Koordination aller Verarbeitungsaktivitä- 
ten der berichtsanbietenden sowie -nachfragenden Unternehmungseinheiten zu 


18 Vgl. Brown/Willis (2003), S. 70. 

19 Inder vorliegenden Arbeit orientiert sich der Begriff eines computergestützten IS an der 
Definition von HANSEN/NEUMANN. Dieser Begriffsauslegung zufolge handelt es sich bei 
einem computergestützten IS um ein System, „bei dem die Erfassung, Speicherung, 
Übertragung und/oder Transformation von Information durch den Einsatz der Informa- 
tionstechnik teilweise automatisiert ist“. Hansen/Neumann (2005), S. 85. Zur Vermei- 
dung einer sprachlichen Monotonie wird in dieser Arbeit der Begriff IT-Systeme syn- 
onym verwendet. Als soziotechnisches System setzt sich ein IS aus menschlichen und 
maschinellen Aufgabenträgern zusammen. Da die Kommunikation zwischen den Sys- 
temelementen eine systemimmanente Eigenschaft eines IS darstellt, wird im weiteren 
Verlauf dieser Arbeit die alternative Bezeichnung Informations- und Kommunikations- 
system (luK-System) nicht verwendet. Vgl. Fink/Schneidereit/Voß (2005), S. 3. Abzu- 
grenzen sind rechnergestützte IS von den Anwendungssystemen, die im vorliegenden 
Arbeitbericht auch als Anwendungen, Applikationen oder betriebliche IS bezeichnet 
werden. Diese Systeme haben die computergestützte Unterstützung eines betrieblichen 
Anwendungs- bzw. Aufgabenbereichs zum Ziel und lassen sich daher neben den Hard- 
waresystemen als Teile eines IS auffassen. Vgl. Fink/Schneidereit/Voß (2005), S. 3f. 

20 Siehe dazu die Berichtszwecke in Abschnitt 2.1.3. Damit folgt das dieser Arbeit 
zugrunde liegende Verständnis eines Berichts der Vorstellung von Kemper/Mehanna/ 
Unger (2004), S. 110. 

21 Vgl. Hirsch/Paefgen/Schaier (2008), S. 326. 


22 Vgl. Göpfert (2002), S. 155. 
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fordern. Damit rückt die Gestaltung der Berichtsprozesse in den Vordergrund 
der Betrachtung. 

Das vorliegende Kapitel widmet sich der Prozessunterstützung im betriebli- 
chen Berichtswesen.23 Der Fokus liegt dabei sowohl auf der Erarbeitung be- 
grifflicher, konzeptioneller und technischer Grundlagen einer Prozessunterstüt- 
zung im Berichtswesen als auch auf der Diskussion aktueller Problemfelder, die 
eine effiziente und effektive Ausführung der Berichtsprozesse verhindern. 

Abschnitt 2.1 widmet sich zunächst den wichtigsten Terminologien und her- 
kömmlichen Sichtweisen auf das betriebliche Berichtswesen. Aus der Perspek- 
tive der Wirtschaftsinformatik interessiert die Frage, wie Berichtssysteme auf- 
gebaut und ausgeprägt sein müssen, um die Ausführung der Berichtsprozesse zu 
ermöglichen. In diesem Zusammenhang ist zu klären, welche Kernprozesse sich 
im betrieblichen Berichtswesen identifizieren lassen. Diese Aspekte werden in 
Abschnitt 2.2 thematisiert. Der darauf folgende Abschnitt 2.3 fokussiert aktuell 
zu beobachtende Defizite, die die Ausführung von Berichtsprozessen behindern. 
Die Störungsursachen betreffen sowohl die Effektivität als auch die Effizienz 
der Informationsverarbeitung innerhalb der Berichtsprozesse. Das Kapitel 
schließt in Abschnitt 2.4 mit einer Zusammenfassung und Würdigung der Pro- 
zessorientierung im Berichtswesen. 


2.1 Terminologische und konzeptionelle Grundlagen zum IT-gestützten 
Berichtswesen 


Das Berichtswesen steht schon seit vielen Jahren im Fokus einer wissenschaftli- 
chen Auseinandersetzung. Abschnitt 2.1.1 obliegt daher zunächst die Vorstel- 
lung und Erörterung verschiedener Sichtweisen zum Begriff des Berichtswe- 
sens. Abschnitt 2.1.2 verfolgt die Zielsetzung, das betriebliche Berichtswesen 
von konkurrierenden Termini abzugrenzen, zu denen die Unternehmenspublizi- 
tät sowie die Rechnungslegung gehören. In Abschnitt 2.1.3 schließt sich die 
Darstellung der Zwecke an, die sich mit dem betrieblichen Berichtswesen ver- 
folgen lassen. 


23 In einem allgemeinen Verständnis lässt sich ein Prozess als eine Folge von logischen, 
miteinander verbundenen Einzelfunktionen auffassen. Vgl. Kremar (2003), S. 99. Aus 
betriebswirtschaftlicher Perspektive ist die Gestaltung von Geschäftsprozessen (business 
processes) von Bedeutung. Als Synopse ausgewählter Definitionsvorschläge lassen sich 
Geschäftsprozesse als betriebswirtschaftlich relevante Prozesse verstehen, die über eine 
zusammengehörige Abfolge von zeitlich und sachlogisch gegliederten Funktionen und 
Ereignissen der Erstellung einer Leistung dienen, die von einem internen oder externen 
Kunden angefordert und abgenommen wird. Vgl. Scheer/Thomas (2005), S. 1069; 
Balzert (2001), S. 126; Fink/Schneidereit/Voß (2005), S. 95; Hansen/Neumann (2005), 


S. 233. 
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2.1.1 Auslegungen des Berichtswesens 


Unter den Vorschlägen zur Abgrenzung des Berichtswesens, dessen englisch- 
sprachiges Pendant als Reporting bezeichnet wird,?4 steht einem engen Defini- 
tionsansatz eine weite Begriffsauslegung gegenüber. Nach dem Verständnis von 
BLOHM als Vertreter einer weiten Sichtweise steht das Berichtswesen für die 
Gesamtheit aller Einrichtungen, Mittel und Maßnahmen, die darauf ausgerichtet 
sind, Informationen über den Betrieb und seine Umwelt zu erarbeiten, weiterzu- 
leiten oder zu verarbeiten.25 Ähnlich kommt die weite Sichtweise des Berichts- 
wesens bei KÜPPER zum Ausdruck. Seiner Auffassung nach sind unter Be- 
richtswesen alle Personen, Organisationseinheiten, Vorschriften, Daten und 
Prozesse zu verstehen, die bei der Produktion sowie der Weitergabe der Berich- 
te maßgeblich sind.26 In beiden Perspektiven wird deutlich, dass für die Gestal- 
tung des Berichtswesens eine ganzheitliche Herangehensweise erforderlich ist, 
im Rahmen dieser neben den zu verarbeitenden Berichtsinformationen auch die 
Organisationsstruktur sowie die anfallenden Prozesse zur Verarbeitung der Be- 
richte zu berücksichtigen sind. Damit umfasst diese Sichtweise sowohl den 
Aufbau als auch den Ablauf des Berichtswesens. 

Im Vergleich zum weiten Begriffsansatz nach BLOHM und KUPPER lässt sich 
das Berichtswesen nach HORVATH enger fassen.?27 Seiner Vorstellung zufolge 
steht das Berichtswesen für die Phase der Informationsübermittlung i. w. S. Als 
Informationstibermittlung i. w. S. versteht HORVATH die Erstellung und Weiter- 
leitung von Berichtsinformationen. Darüber hinaus beschränkt sich die enge 
Sichtweise von HORVÄTH auf die Unternehmungsangehörigen als alleiniger Ad- 
ressatenkreis der Berichte, wobei unter dieser Gruppe die Manager als Ziel- 
gruppe herausragen. Mit Blick auf die Art der berichteten Informationen sind 
für den Austauschprozess insbesondere diejenigen Informationen von Interesse, 
die der Planung und Kontrolle als wichtige Aufgaben des Managements die- 
nen.28 

BECKER/SEIDEL/JANIESCH bemängeln, dass sowohl die weite als auch die en- 
ge Auslegung des Berichtswesens nicht berücksichtigen, dass eine bedarfsge- 


24 In Anlehnung an BECKER/SEIDEL/JANIESCH und GLUCHOWSKI/GABRIEL/DITTMAR wer- 
den die Begriffe Berichtswesen und Reporting im Folgenden synonym verwendet. Vgl. 
dazuBecker/Seidel/Janiesch (2007), S. 605; Gluchowski/Gabriel/Dittmar (2007), S. 205. 

25 Vgl. Blohm (1982), S. 866. 

26 Vgl. Küpper (1997), S. 148. 

27 Vgl. Horvath (2006), S. 583. 

28 Der vorliegenden Arbeit liegt ein funktional geprägtes Managementverständnis zugrun- 
de. Im Vergleich zur institutionellen sowie aktivitätsorientierten Sicht stellt die funktio- 
nelle Perspektive alle Managementhandlungen in den Vordergrund, die sich auf Ent- 
scheidungen beziehen. Entscheidungen zu treffen, diese durchzusetzen und zu hinterfra- 
gen sowie die Verantwortung für die Entscheidungen zu übernehmen, sind demnach ty- 


pische Aufgaben eines Managers. Vgl. Scherm/Pietsch (2008). S. 430f. 
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rechte Informationsversorgung nur gewährleistet werden kann, wenn die her- 
kömmlichen Berichte um geeignete Analyse- und Auswertungssichten ergänzt 
werden.2? Folglich erweitern die Autoren das von BLOHM und HORVATH ge- 
prägte Verständnis zum Berichtswesen um die Notwendigkeit, geeignete Analy- 
se- und Auswertungsperspektiven auf einen verdichteten Datenbestand zur Ver- 
fügung zu stellen, in dem alle relevanten Informationen abgelegt sind.30 Damit 
ist dieses Begriffsverständnis im Vergleich zu den vorangehenden Sichtweisen 
durch eine stärkere Fokussierung auf die softwaretechnische Umsetzung des 
Berichtswesens geprägt.3! 


Datenbe- | | R 
schaffung an | Informations- Informations- 


nd -verwaltung orzeugung übermittlung 


+ Berichtswesen i.e Sf 


|___ Berichtswesen ——______| 
—— Berichtswesen i. w. S. ———_—_——__ 


Abbildung 2: Einordnung des Berichtswesens nach Gipfert>2 


Während im weiten Begriffsverständnis zum Berichtswesen sowohl eine struk- 
turelle als auch eine ablauforientierte Komponente vereint sind, liegt beim Beg- 
riff der Berichterstattung der Fokus auf der ablauforientierten Komponente des 
Berichtswesens. In diesem Zusammenhang versteht BLOHM unter betrieblicher 
Berichterstattung die Vermittlung von Berichten, die über Tatsachen, Ereignis- 
se, Zusammenhänge und Vorgänge aus dem Betrieb und seiner Umwelt infor- 
mieren.?? Mit Blick auf dieses Begriffsverständnis ist zu konstatieren, dass die 
von BLOHM vorgeschlagene Abgrenzung zur Berichterstattung mit der engen 


29 Vgl. Becker/Seidel/Janiesch (2007), S. 607. 

30 Als verdichtete Daten werden in dieser Arbeit alle Informationen verstanden, die je nach 
Informationsbedarf des Berichtsempfängers in konzentrierter bzw. angereicherter Form 
vorliegen. 

31 Siehe dazu die unterschiedlichen Ausprägungen von Berichtssystemen in Abschnitt 
2.2.1.2. 

32 Vgl. Göpfert (2002), S. 146. 


33 Vgl. Blohm (1980), S. 316. 
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Sichtweise des Berichtswesens korrespondiert, wobei der Autor im Gegensatz 
zu HORVATH nicht explizit auf die Manager als alleinige Zielgruppe der Infor- 
mationsversorgung Bezug nimmt. 

Im Vergleich zu den alternativen Sichtweisen präsentiert GOPFERT ein pro- 
zessorientiertes Begriffsverständnis. Wie in der Abbildung 2 zu erkennen ist, 
zeichnet sich der Autorin zufolge das weite Begriffsverständnis im Vergleich 
zur engen Begriffsauslegung durch einen stärkeren Bezug zum Informations- 
prozess aus. Im Gegensatz zum engen Begriffsverständnis nach HORVÄTH um- 
fasst das Berichtswesen im weitesten Sinne nicht nur die Phase der Informati- 
onsübermittlung, sondern die Phasen Datenbeschaffung und -verwaltung, In- 
formationserzeugung und Informationsnutzung. Zwischen diesen beiden Ausle- 
gungen lässt sich nach GÖPFERT der Terminus des Berichtswesens einordnen, 
dessen Kernphasen, wie von HORVÄTH propagiert, die Berichtserzeugung und 
Berichtsdistribution sind.34 


2.1.2 Abgrenzung des Berichtswesens 


Unabhängig von den in Abschnitt 2.1.1 thematisierten Auslegungen des Be- 
richtswesens lässt sich das Reporting eindeutig von anderen betriebswirtschaft- 
lichen Instrumenten abgrenzen, die die Informationsverarbeitung von betriebli- 
chen Informationen fokussieren. Gegenstand der Betrachtung sind in den fol- 
genden Ausführungen die Instrumente der Rechnungslegung und Unterneh- 
menspublizität. 

Wie in der Abbildung 3 deutlich wird, lässt sich die Unternehmenspublizität 
anhand der Informationsinhalte vom Terminus der Rechnungslegung abgren- 
zen.35 In diesem Zusammenhang bezeichnet die Unternehmenspublizität die 
Bekanntmachung von Unternehmungsinformationen, die von einer unbestimm- 
ten Anzahl von Adressaten eingesehen werden können.?6 Im Fokus steht dabei 
die Vermittlung von öffentlichen Informationen, die aus einer gesetzlichen Ver- 
pflichtung heraus oder auf freiwilliger Basis der Öffentlichkeit zugänglich ge- 
macht werden.?? 


34 Vgl. Göpfert (2002), S. 144. 

35 Vgl. Vielmeyer (2004), S. 14. 

36 Vgl. Pellens/Fülbier/Gassen (2006), S. 841. An dieser Stelle ist darauf hinzuweisen, 
dass nicht die tatsächliche Kenntnisnahme bzw. Inanspruchnahme der Unternehmensin- 
formation entscheidend ist, sondern allein die Möglichkeit, die beispielsweise auf der 
Website der Unternehmung veröffentlichten Informationen einzusehen, für das Beg- 
riffsverständnis der Unternehmenspublizität von Bedeutung ist. 

37 Dem Systematisierungsvorschlag von PELLENS/FULBIER/GASSEN zufolge lässt sich die 
Unternehmenspublizität anhand der Kriterien „Grund der Veröffentlichung“, „Zeitpunkt 
und -raum der Veröffentlichung“ sowie „Inhalt der Veröffentlichung“ einteilen. Vgl. 


Pellens/Fülbier/Gassen (2006), S. 846f. 
Alexander Pastwa - 978-3-631-75488-7 


Downloaded from PubFactory at 01/11/2019 04:20:29AM 
via free access 


14 Terminologische und konzeptionelle Grundlagen zum IT-gestützten Berichtswesen 


Rechnungslegung 


= Abgrenzung nach 
ı Informationsinhalten 


Unternehmenspublizität 


= Abgrenzung nach 
= Informationsexklusivitat 


v 


Berichtswesen 


Abbildung 3: Abgrenzung der Begriffe Berichtswesen, Unternehmenspublizität und 
Rechnungslegung’ 


Die Rechnungslegung, die auch als externes Rechnungswesen oder Financial 
Accounting bezeichnet wird, verfolgt hingegen das Ziel, unter Anwendung di- 
verser Vorschriften die Vermögens-, Finanz- und Ertragslage der Unterneh- 
mung abzubilden und auf diese Weise den Außenstehenden Rechenschaft über 
die wirtschaftliche Entwicklung abzulegen. Daraus folgt, dass in der Rech- 
nungslegung nur quantifizierbare Informationen verarbeitet werden, die objek- 
tivierbar sind und in allgemeine Instrumente, zu denen z. B. die Bilanz oder die 
Gewinn- und Verlustrechnung (GuV-Rechnung) gehören, münden.3? Unter- 
nehmungsinformationen, die Gegenstand der Unternehmenspublizität sind, ge- 
hen über die Rechnungslegungsdaten hinaus und umfassen z. B. die Selbstdar- 
stellungen der Unternehmung oder die Einladung zur Hauptversammlung in ei- 
nem Borsenpflichtblatt.4° 

Mit Blick auf die Abbildung 3 kann die Ausrichtung nach dem Empfänger- 
kreis der zu veröffentlichenden Unternehmungsinformationen dazu genutzt 
werden, das betriebliche Berichtswesen von der Unternehmenspublizität abzu- 


38 In Anlehnung an Vielmeyer (2004), S. 14. 
39 Vgl. Vielmeyer (2004), S. 14. 


40 Vgl. Pellens/Fülbier/Gassen (2006), S. 841. 
Alexander Pastwa - 978-3-631-75488-7 


Downloaded from PubFactory at 01/11/2019 04:20:29AM 
via free access 


Prozessunterstützung im betrieblichen Berichtswesen 15 


grenzen. Das separierende Kriterium richtet sich auf die Exklusivität der Infor- 
mationsbereitstellung. In Abgrenzung zum Begriff der Unternehmenspublizität 
zeichnet sich das Berichtswesen einer Unternehmung durch ein umfassendes 
Verständnis aus. Gegenstand des Berichtswesens ist es, sowohl öffentliche als 
auch private Informationen den jeweiligen Anspruchsgruppen einer Unterneh- 
mung in Form von geeigneten Berichten zur Verfügung zu stellen. Im Vergleich 
zu den öffentlichen Informationen zeichnen sich private Informationen durch 
einen höheren Exklusivitätsgrad bei der Informationsgewährung aus, da sie nur 
von einem bestimmten Adressatenkreis verarbeitet werden können.*! Generell 
kommen als potenzielle Berichtsempfänger beispielsweise das Management, die 
Shareholder sowie die Stakeholder einer Unternehmung in Frage.*? Als Stake- 
holder werden alle unternehmungsinternen und -externern Anspruchs- bzw. In- 
teressensgruppen einer Unternehmung bezeichnet.43 Die Einteilung des Be- 
richtswesens nach dem Empfängerkreis der Berichte ist in diesem Zusammen- 
hang das bekannteste Systematisierungskriterium des Reportings.“4 

Richtet sich das Reporting auf die Informationsversorgung unternehmungs- 
interner Angehöriger, wird von internem Berichtswesen gesprochen. Im Mittel- 
punkt der Informationsversorgung stehen die Manager der Unternehmung. Das 
externe Reporting hingegen adressiert den Informationsbedarf von Akteuren, 
die sich außerhalb einer Unternehmung befinden.45 Als unternehmungsexterne 
Stakeholder lassen sich z.B. Kunden, Lieferanten, konkurrierende Unterneh- 
mungen, Medien, der Staat (insbesondere in Form der Kartellbehörde), die öf- 
fentliche Meinung sowie Arbeitgeber- und Arbeitnehmerorganisationen identi- 
fizieren.46 Darüber hinaus richtet sich das externe Berichtswesen auch an die 
Anteilseigner bzw. die Shareholder einer Unternehmung. 

Neben diesen Anspruchsgruppen kommen als potenzielle Berichtsempfänger 
auch Wirtschaftsprüfer in Frage. Bevor die Informationen des externen Rech- 
nungswesens beispielsweise in Form eines Geschäftsberichts der Öffentlichkeit 
zur Verfügung gestellt werden, sind diese durch unabhängige Wirtschaftsprü- 


41 Vgl. Gassen (2000), S. 10f. 

42 Vgl. Gleich et al. (2002), S. 338. 

43 Vgl. Schmidt/Agbor (2008), S. 357. 

44 Vgl. dazu Blohm (1974), S. 16. Als weitere Kriterien kommen z. B. die Informationsart 
(Istwerte, Vorgabewerte, Prognosewerte, etc.), die Erscheinungsweise (regelmäßig, un- 
regelmäßig, überjährig, unterjährig, etc.), die Informationsträger (CD, USB-Stick, Dis- 
kette, Bildschirm, Schriftstück, etc.) oder der Verdichtungsgrad (Ursprungswerte, Kenn- 
zahlen, etc.) in Frage. Vgl. Göpfert (2002), S. 148. 

45 Der Definition von VOM BROCKE/BUDDENDICK folgend, können Akteure als handlungs- 
fähige Einheiten verstanden werden, die vor dem Hintergrund ihres eigenen Zielsystems 
handlungsorientiert agieren und dabei ihre kommunikativen und kognitiven Fähigkeiten 
einsetzen. Vgl. vom Brocke/Buddendick (2004), S. 342. 


46 Vgl. Leitl (2006), S. 10; Pellens/Fülbier/Gassen (2008), S.4 
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fer(-Gesellschaften) auf ihre Richtigkeit zu untersuchen.’ Neben den Wirt- 
schaftsprüfern existiert mit den Informationsintermediären ein weiterer Be- 
richtsempfängerkreis, der als Zielgruppe des Unternehmensreportings von Be- 
deutung sein kann. Die Aufgabe der Informationsintermediäre liegt darin, die 
von einer Unternehmung berichteten Informationen zu sammeln, aufzubereiten 
und in einem nächsten Schritt einer undifferenzierten oder ausgewählten End- 
verbrauchergruppe zur Verfügung zu stellen. Eine derartige Dienstleistung kann 
gegen Entgelt oder entgeltlos erfolgen. Als Informationsintermediäre kommen 
z.B. diverse Wirtschaftsinstitute, Wirtschaftsverbände, Gewerkschaften, Bör- 
senplattformen, Nachrichtendienste oder Beratungsunternehmungen in Frage. 
Vor dem Hintergrund dieses Begriffsverständnisses schließt das betriebliche 
Berichtswesen auch die Unternehmenspublizität ein. 


2.1.3 Berichtszwecke 


Wie aus den bisherigen Ausführungen hervorgeht, zielt das Reporting auf die 
Informationsversorgung mit Hilfe von Berichten, in denen die entsprechenden 
Geschäfts- und Finanzinformationen präsentiert sind.48 In der Literatur werden 
hierzu drei Berichtszwecke genannt, die Gegenstand der folgenden Ausführun- 
gen sind.49 

1. Der erste Aufgabenbereich liegt in der Dokumentation von Ereignissen mit 
dem Ziel, das Betriebsgeschehen in einer strukturierten Form abzubilden. Der 
Berichtszweck der Dokumentation richtet sich auf alle Informationen, die aus 
einer rechtlichen bzw. gesetzlichen Verpflichtung heraus von einer Unterneh- 
mung protokolliert werden müssen. Eine entsprechende Verpflichtung zur Do- 
kumentation von Berichten resultiert aus den entsprechenden Vorschriften des 
Handels-, Aktien-, Steuer- und Umweltrechts. 

Neben dem Handelsgesetzbuch als Bilanzierungsstandard im deutschen 
Raum haben in den vergangenen Jahren insbesondere die International Accoun- 
ting Standard / International Financial Reporting Standards (IAS/IFRS) als in- 
ternationaler Rechnungslegungsstandard an Bedeutung gewonnen.50 Wird eine 
Aufnahme an der amerikanischen Börse angestrebt, ist nach den United States 
Generally Accepted Accounting Principles (US-GAAP) zu bilanzieren.5! Als 
einer der wichtigsten Berichte ist in diesem Zusammenhang der Jahresabschluss 


47 Vgl. Wagenhofer (2003), S. 264. 

48 Vgl. dazu auch Leßweng (2003), S. 335. 

49 Vgl. Göpfert (2002), S. 147. HIRSCH/PAEFGEN/SCHAIER bemerken in diesem Zusam- 
menhang, dass bei allen Berichtszwecken der übergeordnete Zweck der Informations- 
versorgung überwiegt. Vgl. Hirsch/Paefgen/Schaier (2008), S. 327. 

50 Vgl. Gluchowski/Gabriel/Dittmar (2007), S. 234. 

51 Zu den Pflichten einer berichterstattenden Unternehmung aus der Perspektive von IFRS, 


US-GAAP und HGB vgl. Bellen Bu DIE (assen (2006), S. 127ff. 
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zu nennen, der sich im Falle einer Anwendung von IFRS aus einer Bilanz, einer 
GuV-Rechnung, einer Kapitalflussrechnung, einer Eigenkapitalveränderungs- 
rechnung sowie Anhangangaben zusammensetzt.52 Neben den Berichten, die 
aus einer gesetzlichen Dokumentationsverpflichtung heraus zu erstellen sind, 
leisten auch alle Dokumentationen, die eine Unternehmung freiwillig bzw. zur 
Selbstinformation generiert, einen wichtigen Beitrag zur Unternehmungssteue- 
rung.>> 

2. Ein weiterer Berichtszweck lässt sich in der Auslösung von Aktivitäten 
identifizieren. Dadurch, dass beispielsweise eine negative Abweichung gegen- 
über einem Plan-/Sollwert in einem entsprechenden Bericht angezeigt wird, 
sind die Voraussetzungen dafür geschaffen, dass eine Unternehmensführung 
frühzeitig Einfluss auf das Unternehmungsgeschehen nehmen kann. Wie unter- 
nehmungsinterne Entwicklungen zur Entscheidungsunterstützung sowie zur Ab- 
leitung von gegensteuernden Maßnahmen führen, so können auch unterneh- 
mungsexterne Berichte, die von oder über Konkurrenzunternehmungen erstellt 
werden, zu einer entsprechenden Reaktion der Unternehmungsleitung beitragen. 

3. Der letzte Aufgabenbereich des Berichtswesens richtet sich auf die Vorbe- 
reitung und Kontrolle von Entscheidungen.5* Das Ziel des Reportings liegt dar- 
in, durch die Bereitstellung geeigneter Informationen alle Phasen des Manage- 
mentprozesses zu begleiten und zu unterstützen. Einerseits lassen sich Berich- 
te zur Entscheidungsfindung bzw. Entscheidungsvorbereitung einsetzen.56 Zum 
anderen dienen die berichteten Informationen auch zur Unterstiitzung bei der 
Entscheidungsdurchsetzung bis hin zur Entscheidungskontrolle.57 

Kommen für die Produktion und/oder Präsentation der Berichte verschiedene 
Softwaresysteme und Werkzeuge zum Einsatz, wird die daraus resultierende 
technische Gesamtlösung als (computergestütztes) Berichtssystem bezeichnet.5® 
Gegenstand des folgenden Abschnitts ist die Frage, welche grundlegende Struk- 
tur und Ausprägungen eines Berichtssystems sich zur Unterstützung des Repor- 
tings identifizieren lassen. 


52 Vgl. Pellens/Fiilbier/Gassen (2006), S. 151. 

53 Vgl. Göpfert (2002), S. 147. 

54 Vgl. Göpfert (2002), S. 147. 

55 Als Phasen lassen sich in diesem Zusammenhang die Situationsanalyse, Planung i. e. S., 
Organisation und Steuerung sowie Kontrolle identifizieren. Vgl. Gluchowski/Gabriel/ 
Dittmar (2007), S. 21 ff. 

56 Vgl. Gluchowski (2006), S. 210. 

57 Vgl. Gluchowski (2006), S. 210; Göpfert (2002), S. 147. 

58 Vgl. Gluchowski (2006), S. 208. BLOHM weist darauf hin, dass in der Literatur der Beg- 
riff Berichtssystem synonym zum Terminus Berichtswesen verwendet wird. Vgl. Blohm 
(1980), S. 315. Dieser Sichtweise wird in der vorliegenden Arbeit nicht gefolgt. Statt- 
dessen werden Berichtssysteme als IT-gestützte IS zur Unterstützung der Berichts- 


zwecke verstanden. 
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2.2 Berichtssysteme zur informationstechnischen Unterstützung von Be- 
richtsprozessen 


In der Auslegung des Berichtswesens nach GÖPFERT ist bereits deutlich gewor- 
den, dass das Berichtswesen im weitesten Sinne sich als Informationsprozess 
verstehen lasst.5? Ausgehend von der Vorstellung der Informationstechnik (Ab- 
schnitt 2.2.1), die heute zur Unterstützung der anfallenden Berichtsprozesse 
zum Einsatz kommt, werden in Abschnitt 2.2.2 die Kernprozesse des Berichts- 
wesens präsentiert. 


2.2.1 Berichtssysteme als Anwendungsbereich von Business Intelligence 


Der folgende Abschnitt befasst sich mit der informationstechnischen Unterstüt- 
zung des Berichtswesens. Dabei geht es im Abschnitt 2.2.1.1 zunächst um das 
Business Intelligence-Konzept, das sich als technischer und konzeptioneller Be- 
zugsrahmen zur Gestaltung von Berichtsanwendungen etabliert hat.60 Die Frage 
nach einer geeigneten Klassifizierung von Berichtssystemen wird in Abschnitt 
2.2.1.2 aufgegriffen. 


2.2.1.1 Business Intelligence-Systeme (BI-Systeme) als übergeordnete 
Systemkategorie zur Gestaltung und Einordnung von Berichts- 
anwendungen 


Obwohl die Begrifflichkeit Business Intelligence (BI) in den letzten Jahren das 
Stadium eines neuen IT-Schlagworts verlassen hat und eine Reihe BI-tauglicher 
Anwendungen implementiert wurden,$! ist zu konstatieren, dass in der Literatur 
nach wie vor eine Reihe von Definitionen und Begriffsauslegungen zu BI exis- 
tieren.62 Bisher ist es nicht gelungen, aus diesen Vorschlägen eine allgemein 
akzeptierte Definition von BI zu etablieren.®3 In einem integrierten Begriffver- 
ständnis lässt sich BI als Gesamtheit aller Methoden, Technologien und Prozes- 


59 Vgl. Abschnitt 2.1.1. 

60 NAVRADE und MUKSCH/BEHME zufolge stehen das Berichtswesen sowie die betriebli- 
chen Berichtssysteme für den informationsorientierten Anwendungsbereich von Busi- 
ness Intelligence-Systemen. Vgl. Navrade (2006), S. 12; Muksch/Behme (2001), S. 23f. 

61 Vgl. dazu Głuchowski (2001), S. 5. Erfolgreiche BI-Projekte präsentieren z.B. 
Gabriel/Hoppe/Pastwa (2008), S. 287ff.; Hoppe/Pastwa (2007), S. 39ff.; Grothe (2005), 
S. 138 ff. 

62 Vgl. Leßweng (2004), S. 42; Liebowitz (2006), S. 19. Siehe dazu die Übersicht über 
verschiedene BI-Definitionen bei Kemper/Mehanna/Unger (2004), S. 2ff. Einen Ord- 
nungsrahmen zur Positionierung eines engen, analyseorientierten und weiten BI- 
Verständnisses präsentiert Gluchowski (2001), S. 7f. 


63 Vgl. Gluchowski/Kemper (2006), S. 14. 
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se mit entscheidungsunterstützendem Charakter verstehen, die zur besseren Ein- 
sicht in das eigene Geschäft und damit zum besseren Verständnis in die Mecha- 
nismen relevanter Wirkungsketten führen.6 Mit Blick auf diese Abgrenzung 
des BI-Begriffs steht dieser für eine begriffliche Klammer, die eine Vielzahl un- 
terschiedlicher Ansätze, Werkzeuge sowie Anwendungen zur Analyse ge- 
schäftsrelevanter Daten zu bündeln versucht.65 Zu diesen gehört beispielsweise 
der Einsatz eines Data Warehouse (DWH), das die zentrale und einheitliche Da- 
tenbasis für die Implementierung eines BI-Systems repräsentiert.66 Dabei fokus- 
siert BI die integrierte Nutzung sowohl strukturierter als auch unstrukturierter 
Informationen, um eine möglichst fundierte Entscheidungsunterstützung zu ge- 
währleisten.67 

I. d. R. liegen die Daten einer Unternehmung in verschiedenen Systemen vor, 
so dass eine Zusammenführung der Daten erforderlich ist.68 Wie sich der 
Abbildung 4 entnehmen lässt, sind auf der untersten Ebene der BI-Referenz- 
architektur diverse unternehmungsinterne operative Vorsysteme sowie poten- 
zielle externe Datenquellen positioniert. Sie dienen als Datenlieferanten für das 
DWH, das als Datenspeicher Bestandteil der mittleren Schicht ist. 

Ein DWH stellt eine einheitliche, vollständige und konsistente Sammlung 
von Daten dar, die aus verschiedenen Quellen stammen und von verschiedenen 
Anwendern genutzt werden kénnen.®? Die Daten aus den Vorsystemen werden 
in bestimmten zeitlichen Abständen im DWH zusammengeführt.”° Das DWH 
wird neben den operativen Systemen bzw. Online-Transaction-Processing- 
Systemen (OLTP-Systemen) betrieben. Letztere sind auf die Verarbeitung von 
Massendaten sowie die Ausführung zeitkritischer, in großer Anzahl vor- 
kommender Transaktionen ausgerichtet.’! Im Gegensatz zu diesen Systemen 


64 Vgl. Gluchowski (2001), S. 14.; Dittmar/Schulze (2006), S. 27; Chamoni/Linden 
(2007), S. 1588; Wenzke (2005), S. 631; Wall (2008), S. 82. Das umfassende BI- 
Verständnis integriert sowohl den klassischen als auch den prozessorientierten BI- 
Begriff. Während der klassische BI-Begriff tendenziell für ein statisches, vergangen- 
heitsbezogenes Reporting und die Analyse von Fehlentwicklungen steht, fokussiert die 
prozessorientierte Perspektive die Planung, Verbesserung und Steuerung von Prozessen. 
Vgl. Seufert/Schiefer (2008), S. 21. 

65 Vgl. Gluchowski/Gabriel/Dittmar (2007), S. 93. 

66 Vgl. Kruppke/Bauer (2005), S. 79. 

67 Vgl. Raimann/Mähler (2006), S. 39. 

68 Vgl. Hahn (2003), S. 605. 

69 Vgl. Devlin (1997), S. 20.; Frosch-Wilke (2003), S. 597. 

70 Vgl. Stock/Düsing (2003), S. 186. 


71 Vgl. Harder/Rahm (2001), S. 500. 
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stellt ein DWH die Datenbasis für dispositive und strategische Aufgaben zur 
Verfügung.’ 
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Abbildung 4: Aufbau eines BI-Systems”3 


Ein Transfer der Daten aus den Vorsystemen in das DWH erfolgt unter dem 
Einsatz einer ETL-Komponente, die für die Teilschritte Extract (Extraktion), 
Transform (Transformation) und Load (Laden) steht.74 Als Schnittstelle zwi- 
schen den Vorsystemen und dem DWH bildet diese einen weiteren Baustein der 
BI-Architektur. Dabei ist die ETL-Komponente für die Umwandlung der hete- 
rogenen Daten in einen konsistenten und homogenen Bestand sowie das Laden 
dieser Daten in das DWH verantwortlich. Der Teilschritt der Extraktion sorgt 
dabei für die Selektion und Bereitstellung der Quelldaten für den weiteren Pro- 


72 Vgl. Petersohn (2005), S. 40. Zu den Auswirkungen und Nutzungspotenzialen eines 
DWH, die sich im Rahmen einer Literaturanalyse identifizieren ließen, vgl. Kink/ 
Höhne/Hess (2008), S. 9. 

73 Aus Gluchowski/Kemper (2006), S. 14. 

74 ~~ Zu den einzelnen Phasen und Teilschritten des ETL-Prozesses vgl. Gluchowski/Gabriel/ 
Dittmar (2007), S. 133ff.; Kemper/Mehanna/Unger (2004), S. 23ff.; Bange (2004), S. 


85ff.; Stock/Büttner (2004), S. 1067f. 
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zess. Da die Daten der Vorsysteme typischerweise in sehr heterogener Form 
vorliegen, muss das ETL-Werkzeug den Zugriff auf alle Daten aus den unter- 
schiedlichsten Vorsystemen ermöglichen. Die Transformation als zentrale Auf- 
gabe des ETL-Prozesses bezeichnet die Umwandlung der Ausgangsdaten in das 
DWH-Zielformat. Weiterhin lässt sich der Transformationsprozess in die Teil- 
schritte der Filterung, Harmonisierung, Aggregation und Anreicherung aufglie- 
dern. 

Schließlich werden die extrahierten und transformierten Daten in das DWH 
geladen und dauerhaft abgelegt. Um eine zeitnahe Bereitstellung der Daten zu 
gewährleisten, ist in diesem Zusammenhang zu klären, in welchen Zeitinterval- 
len die Daten der operativen Systeme in das DWH geladen werden müssen, um 
eine ausreichende Aktualität und Qualität der Informationsversorgung zu er- 
möglichen. Je nach Anwendungsbereich lassen sich die aus den Vorsystemen 
stammenden und im Vorfeld ausgewählten Daten beispielsweise einmal pro 
Monat, einmal pro Woche oder auch täglich transferieren. 

Einer der zentralen Erfolgsfaktoren für die Gestaltung einer BI-Anwendung 
ist die Modellierung einer geeigneten multidimensionalen Datenstruktur.’5 Als 
Bindeglied zwischen den Datenquellen und den Benutzern dient das Datenmo- 
dell zur Realisierung der ETL-Prozesse.’6 Beim Modellierungsprozess liegt eine 
der wesentlichen Aufgaben in der Identifizierung relevanter Dimensionen und 
Fakten. Dimensionen stellen qualitative Informationsobjekte dar, die dazu die- 
nen, die Variablen bzw. Kennzahlen zu beschreiben und auszuwerten.’ I. d. R. 
kommt bei einer DWH-Anwendung eine Reihe von Dimensionen zum Ein- 
satz.’8 Mit Hilfe von Dimensionshierarchien lassen sich die Kennzahlen aggre- 
gieren bzw. disaggregieren.’? Kennzahlen stehen für die quantitativen Werte, 
die sich unter betriebswirtschaftlichen Gesichtspunkten auswerten lassen.80 
Werden die Kennzahlen in einer sachlich sinnvollen Beziehung zueinander ge- 
setzt, so ergeben sich daraus Kennzahlensysteme.3! Die Implementierung mul- 


75 Vgl. Hahn (2003), S. 606. 

76 Vgl. Bange (2004), S. 95. Datenmodelle beschreiben den zu modellierenden Realitäts- 
ausschnitt in formaler Form. Ein Datenmodell liefert Informationen über die Struktur 
der Daten, die Beziehungen zwischen und innerhalb der Datenobjekte, Wertebereiche 
sowie Integritätsbedingungen. Vgl. Pernul/Unland (2003), S. 10. 

77 Vgl. Hettler/Preuss/Niedereichholz (2003), S. 97. 

78 Um die Multidimensionalität des Datenraums bildhaft darzustellen, hat sich in der Lite- 
ratur die Metapher eines Datenwürfels bzw. Daten-Cubus etabliert. 

79 Vgl. Becker/Knackstedt (2004), S. 40. 

80 Vgl. Hettler/Preuss/Niedereichholz (2003), S. 97. 


81 Vgl. Liebetruth/Otto (2006), S. 13. 
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tidimensionaler Datenstrukturen ist sowohl mit relationalen als auch multidi- 
mensionalen Datenbanksystemen möglich.3? 

Auf der obersten Ebene der Referenzarchitektur befinden sich alle Methoden 
und Werkzeuge, mit deren Hilfe sich der multidimensional abgebildete und 
konsolidierte Datenbestand, der sich infolge der physischen Aufbereitung er- 
gibt, auswerten lässt. Unter den verschiedenen Möglichkeiten zur Datenaus- 
wertung sowie zur Präsentation der Berichte spielen das Online Analytical Pro- 
cessing (OLAP) sowie das Data Mining eine große Rolle.8 Unter dem Akro- 
nym OLAP verbirgt sich eine Softwaretechnologie, die es den jeweiligen Ent- 
scheidungsträgern ermöglicht, schnelle, interaktive und vielfältige Zugriffe auf 
die relevanten, im multidimensionalen Datenmodell abgelegten Daten durchzu- 
führen.8* Während die „Klassischen“ OLAP-Operationen Slicing, Dicing, Drill- 
Down und Roll-Up tendenziell vergangenheitsorientierte Analysen ermögli- 
chen,85 liegt der Fokus von Data Mining auf der prospektiven Auswertung eines 
Datenbestands. Durch den Einsatz diverser Algorithmen und Methoden wird 
das Ziel verfolgt, in einem aufbereiteten Datenbestand interessante Muster zu 
erkennen, die für die Beantwortung einer konkreten Frage- bzw. Problemstel- 
lung relevant sein kénnen.86 Im Gegensatz zur OLAP-Technologie, die die 
Überprüfung von Hypothesen unterstützt, ist das Data Mining-Konzept darauf 
ausgerichtet, möglichst selbständig Hypothesen auf Basis der identifizierten 
Muster zu formulieren.3? 


2.2.1.2 Ausprägungen von Berichtssystemen 


Wie KEMPER/MEHANNA/UNGER bemerken, zeichnen sich Berichtssysteme unter 
allen Analysesystemen, die sich als BI-Systeme auffassen lassen, durch die 


82 Vgl. Gabriel/Röhrs (2003), S. 371. Zur logischen Modellierung einer multi- 
dimensionalen Datenstruktur mit Hilfe von Relationen lassen sich verschiedene Varian- 
ten nutzen. Zu den gebräuchlichsten zählen das Star-Schema (Stern-Schema), das 
Snowflake-Schema (Schneeflocken-Schema) und das Fact-Constellation-Schema. Vgl. 
Becker/Knackstedt (2004), S. 41. Zu den Eigenschaften und Unterschieden dieser Mo- 
dellierungsvarianten vgl. Gabriel/Röhrs (2003), S. 371ff.; Frosch-Wilke (2003), S. 599f. 

83 Vgl. Schwarz et al. (2003), S. 196. Zu den Grundlagen des Data Mining und OLAP vgl. 
Petersohn (2005), S. 48ff. 

84 Vgl. Gabriel/Röhrs (2003), S. 350. 

85 Zu den gebräuchlichen OLAP-Operationen vgl. Kemper/Mehanna/Unger (2004), S. 
95ff.; Gluchowski/Gabriel/Dittmar (2007), S. 148ff. und 171f.; Oehler (2006), S. 27f.; 
Jarke et al. (2000), S. 90. 

86 Vgl. Gabriel/Röhrs (2003), S. 344f. 


87 Vgl. Schwarz et al. (2003), S. 196. 
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größte Erscheinungsvielfalt aus.88 Einen Vorschlag zur Klassifizierung der ver- 
schiedenen Ausprägungen eines Berichtssystems liefert Abbildung 5.89 


Berichtssysteme 


Aktive Berichtssysteme Passive Berichtssysteme 


Periodische Aperiodische 
Berichtssysteme Berichtssysteme Ad-hoc- 


Berichtssysteme 
(Standardberichtswesen) (Früherkennungssysteme) 


Abbildung 5: Übersicht zur Einordnung von Berichtssystemen? 


Auf der obersten Ebene lassen sich Berichtssysteme nach dem auslösenden 
Moment einer Berichtserstellung systematisieren.?! Hierbei stehen den aktiven 
Berichtssystemen die passiven gegentiber.92 Während bei aktiven Berichts- 
systemen die Erstellung und Veröffentlichung der Berichte durch die betriebe- 
nen IS ausgelöst wird, fordern passive Berichtssysteme ihre Nutzer dazu auf, 
selbständig auf den zugrunde liegenden Informationsbestand zuzugreifen und 
Berichte zu erstellen. 


88 Vgl. Kemper/Mehanna/Unger (2004), S. 111. Mit Blick auf die von KEMPER/MEHANNA/ 
UNGER präsentierte Übersicht zur Einordnung von Analysesystemen für das Manage- 
ment lassen sich Berichtssysteme als Ausprägung eines generischen BI-Basissystems 
auffassen. Zusammen mit den konzeptorientierten Systemen bilden die generischen Ba- 
sissysteme die beiden Kategorien eines BI-Systems. Zu diesen beiden Kategorien vgl. 
Kemper/Mehanna/Unger (2004), S. 83f. 

89 _ HANSEN/NEUMANN präsentieren einen alternativen Ansatz zur Systematisierung von Be- 
richtssystemen. Vgl. Hansen/Neumann (2005), S. 777ff. 

90 In Anlehnung an Gluchowski (1998), S. 1178. 

91 Der hier gewählte Einstiegspunkt zur Systematisierung von Berichtssystemen geht da- 
mit mit der Erkenntnis GÖPFERTS einher, nach deren Auffassung sich die Unterschei- 
dung nach der Erscheinungsweise eines Reports sowie nach dem auslösenden Ereignis 
der Berichtserstellung zur Einteilung der verschiedenen Berichtsarten durchgesetzt hat. 
Vgl. Göpfert (2002), S. 148. 


92 Vgl. Gluchowski (1998), S. 1178. 
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Charakteristisch für aktive Berichtssysteme ist, dass die Berichte nach einem 
bestimmten, im Vorfeld zu definierenden Muster erstellt und dem jeweiligen 
Empfänger(-kreis) präsentiert werden.?3 Hierzu sind im Vorfeld als quasi ein- 
maliger Aufwand die relevanten Berichtsinhalte, der strukturelle Aufbau sowie 
die graphische Darstellung der Reports zu definieren. Auf einer feineren Stufe 
werden innerhalb der Kategorie der aktiven Berichtssysteme die periodischen 
von den aperiodischen Berichtssystemen unterschieden. 

Periodische Berichtssysteme lassen sich für die Zwecke eines Standardbe- 
richtswesens einsetzen. Charakteristisch für ein derartiges Berichtssystem ist, 
dass den Berichtsempfängern die für sie relevanten Informationen in Form stan- 
dardisierter Berichte zur Verfügung stehen.?* Die Berichte werden auf Basis der 
im Vorfeld definierten Berichtsinhalte, Struktur sowie graphischen Darstellung 
in einem zyklischen Bereitstellungsprozess oder im Rahmen einer bedarfsorien- 
tierten Anfrage erstellt bzw. veröffentlicht.?5 Die Veröffentlichung der Reports 
erfolgt i. d. R. in festgelegten Zeitabständen. Vor dem Hintergrund eines lang- 
fristig sich nur geringfügig ändernden Informationsbedarfs der Berichts- 
empfänger ist das Standardberichtswesen folglich auf eine kontinuierliche so- 
wie stabile Informationsversorgung ausgerichtet. 

Neben einer starren Struktur können die Reports eines Standard- 
berichtswesens einen variablen Aufbau aufweisen, um beispielsweise Ausnah- 
memeldungen, Abweichungen sowie eingetretene Unter- und/oder Überschrei- 
tungen vorgegebener Schwellenwerte anzuzeigen.?6 Für eine anschauliche Prä- 
sentation der Berichte lassen sich Tabellen, Grafiken wie z.B. Torten- oder 
Balkendiagramme sowie geografische Abbildungen beispielsweise in Form ei- 
ner Landkarte verwenden.?? 

Während periodische Berichtssysteme in festen bzw. regelmäßigen Zeitab- 
ständen Berichte erstellen, wird bei aperiodischen Berichtssystemen ein Report 
nach dem Eintreffen einer besonderen Datenkonstellation — beispielsweise im 
Fall einer Abweichung von Normwerten — generiert.?® Derartige Berichtssyste- 
me werden auch als Früherkennungssysteme oder indikatorbasierte Frühwarn- 
systeme bezeichnet.?? Der Einsatz von Früherkennungssystemen ermöglicht die 
Implementierung eines Ausnahmeberichtswesens, das auch als Exception Re- 
porting bezeichnet wird. In diesem Zusammenhang dienen Agenten und andere 
regelgesteuerte Mechanismen dazu, nach Eintritt eines bestimmten Ereignisses 


93 Vgl. dazu Gluchowski/Gabriel/Chamoni (1997), S. 48f. 

94 Ein Beispiel für den Einsatz eines Standardberichtswesens in einem Lebensmittelfilial- 
betrieb liefern Hansen/Neumann (2005), S. 780. 

95 Vgl. Bange (2004), S. 94. 

96 Vgl. Gluchowski (1998), S. 1178. 

97 Vgl. Bange (2004), S. 95. 

98 Vgl. dazu Gluchowski/Gabriel/Chamoni (1997), S. 48. 


99 Vgl. Gluchowski (1998), S. 1178; Gluchowski/Gabriel/Chamoni (1997), S. 48f. 
Alexander Pastwa - 978-3-631-/5488-7 


Downloaded from PubFactory at 01/11/2019 04:20:29AM 
via free access 


Prozessunterstützung im betrieblichen Berichtswesen 25 


dem vorgesehenen Empfänger(-kreis) entsprechende Berichte zur Verfügung zu 
stellen. Als derartige Ereignisse kommen beispielsweise ein bestimmter Zeit- 
punkt, die Verfügbarkeit von Daten für die Berichtserstellung sowie die Auf- 
nahme bestimmter Werte in eine Datenbank in Frage.100 

Im Gegensatz zu einem IT-gestützten Standardberichtswesen wird durch 
Früherkennungssysteme gewährleistet, dass wichtige Entwicklungen, die im 
Rahmen eines Standardberichtswesens erst zu einem späteren Zeitpunkt oder 
möglicherweise gar nicht erkannt würden, durch eine automatische Benachrich- 
tigung des Systems — beispielsweise per Mail — aufgedeckt werden, !0! so dass 
die Möglichkeit einer zeitnahen Einflussnahme des betrieblichen Entschei- 
dungsträgers auf die Unternehmungsentwicklung gewahrt werden kann. 

In Abgrenzung zu den aktiven Berichtssystemen zeichnen sich passive Be- 
richtssysteme dadurch aus, dass sie nicht selbständig Berichte generieren, son- 
dern auf die Anfrage des Benutzers warten.!% Mit Blick auf die Passivität des 
Berichtssystems bzw. die aktive Rolle Berichterstellers lässt sich ein solches 
System auch als Abfrage- oder Auskunftssystem bezeichnen.!0% Als Ausprä- 
gung eines passiven Berichtssystems haben sich so genannte Ad-hoc- 
Berichtssysteme etabliert.!°4 In Abgrenzung zum Standardberichtswesen fokus- 
sieren Ad-hoc-Berichtssysteme auf den spontanen bzw. unregelmäßigen Zugriff 
auf die Daten der Unternehmung, in denen die relevanten Berichtsinformatio- 
nen vorliegen. Als Ergebnis einer Datenabfrage können die generierten Berichte 
dabei in einer starren oder variablen Struktur angezeigt werden.!05 

I. d. R. unterliegt der Informationsbedarf der Berichtsempfänger, die ein Ad- 
hoc-Berichtssystem nutzen, stärkeren Schwankungen bzw. Änderungen, so dass 
ein höheres Maß an Flexibilität bei dem Zugriff auf die Informationen zu for- 
dern ist. Für die Erstellung der Berichte lassen sich verschiedene Berichtswerk- 
zeuge einsetzen, die wiederum auf verschiedene Datenquellen zugreifen kön- 
nen. Zwischen diese beiden Komponenten wird ein Datenmodell geschaltet, um 
den zu berichtenden Realitätsausschnitt auf einer semantischen sowie logischen 
Ebene abzubilden.!06 Mit Blick auf den Eigenanteil des Informationsempfän- 
gers bei der Berichterstellung sind von diesem IT-Kenntnisse zu erwarten.!07 
Kommt zur Implementierung eines Ad-hoc-Systems ein Datenbanksystem zum 
Einsatz, muss der Benutzer zur Erzielung eines gewünschten Abfrageergebnis- 


100 Vgl. Bange (2004), S. 95. 

101 Vgl. Kemper/Mehanna/Unger (2004), S. 111f. 

102 Vgl. Gluchowski/Gabriel/Chamoni (1997), S. 49f.; Kemper/Mehanna/Unger (2004), 
S. 112. 

103 Vgl. Gluchowski (1998), S. 1178. 

104 Vgl. Kemper/Mehanna/Unger (2004), S. 112. 

105 Vgl. Gluchowski (1998), S. 1178. 

106 Vgl. Bange (2004), S. 95. 


107 Vgl. Kemper/Mehanna/Unger (2004), S. 112. 
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ses beispielsweise Kenntnisse der Datenstrukturen besitzen.!08 Für die Erstel- 
lung der Berichte sowie für die Implementierung eines leistungsfähigen Be- 
richtssystems sind folglich hohe Anforderungen zu erfüllen.!09 


2.2.2 Kernprozesse des betrieblichen Berichtswesens 


Der vorliegende Abschnitt verfolgt das Ziel, die Kernprozesse des betrieblichen 
Berichtswesens zu präsentieren. Unter Einbezug der Beiträge von LEBWENG und 
KEMPER/MEHANNA/UNGER, die sich neben GÖPFERT mit den relevanten Prozes- 
sen im Berichtswesen beschäftigt haben,!!0 lassen sich mit der Informationsbe- 
schaffung, Berichtsproduktion, Berichtsdistribution und Berichtsaufnahme vier 
Kernprozesse des Reportings identifizieren. Die Kernprozesse fokussieren die 
Verarbeitung der Geschäfts- und Finanzinformationen und stellen gleichsam die 
vier Teilprozesse eines Berichtsprozesses dar. Abbildung 6 verdeutlicht die An- 
ordnung der Prozesse. 


zn Berichts- IN Berichts- I5 Berichts- i 


beschaffung erstellung distribution aufnahme 


Abbildung 6: Phasen des Berichtsprozesses 


2.2.2.1 Informationsbeschaffung 


Der Teilprozess Informationsbeschaffung umfasst Aktivitäten, die zum Ziel ha- 
ben, alle Daten und Informationen, die zur Berichtserstellung erforderlich sind, 
zu identifizieren, in den betreffenden IS zusammenzuführen, dort dauerhaft ab- 
zulegen und zu verwalten. Als Daten- und Informationsquellen kommen zum 
einen unternehmungsinterne Systeme in Frage, die die zu beschaffenden Infor- 
mationen entweder in einer strukturierten oder unstrukturierten Form vorhalten. 
Unstrukturierte bzw. schwach strukturierte Informationen zeichnen sich durch 
eine geringe gemeinsame innere Struktur aus.!!! In einem erweiterten Verständ- 


108 Vgl. Gluchowski (1998), S. 1178. 

109 Eine Zusammenfassung der Grundsätze bzw. Gestaltungsregelen, die für die Imple- 
mentierung eines Berichtssystems einzuhalten sind, liefern BLOHM und GÖPFERT. Vgl. 
Blohm (1980), S. 319; Göpfert (2002), S. 152. 

110 Vgl. Leßweng (2003a), S. 335ff.; Leßweng (2003b), S. 86ff.; Leßweng (2004), S. 42; 
Kemper/Mehanna/Unger (2004), S. 110f.; Göpfert (2002), S. 144ff. 


111 Vgl. Bange (2004), S. 17. 
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nis eignen sich neben Textdaten, die beispielsweise in Internetseiten, E-Mails 
oder abgespeicherten Berichten enthalten sind, auch Bilder, Tonaufzeichnungen 
und Videos als Quellen unstrukturierter Informationen. Da die für die Berichts- 
produktion interessanten Inhalte auch von außerhalb der Unternehmung stam- 
men können,!!2 sind auch unternehmungsexterne Quellen bei der Informations- 
beschaffung zu berücksichtigen. 

Als datenhaltende Systeme zur Verwaltung strukturierter Daten werden Da- 
tenbanksysteme eingesetzt, die sich sowohl für die Verarbeitung operativer 
transaktionsorientierter Daten als auch für analyseorientierte Zwecke z. B. im 
Rahmen von Berichtssystemen eignen.!!3 Wird die Verarbeitung von unstruktu- 
rierten Informationen angestrebt, lassen sich Dokumentenmanagementsysteme 
(DMS) nutzen. Derartige IS werden mit dem Ziel eingesetzt, elektronische Do- 
kumente im Rahmen von organisatorischen Prozessen zu speichern, zu verwal- 
ten, zu archivieren und über geeignete Suchkriterien den Anwendern wieder zu- 
gänglich zu machen.!!4 

Kommt ein DWH-gestiitztes Berichtssystem zum Einsatz, fokussiert der 
Teilprozess Informationsbeschaffung nicht nur den manuellen Import der be- 
richtsrelevanten Daten und Informationen in die Vorsysteme einer derartigen 
Applikation. Unter Informationsbeschaffung wird darüber hinaus auch die 
Durchführung eines ETL-Prozesses verstanden, mit dessen Hilfe die berichtsre- 
levanten Daten und Informationen aus den Vorsystemen extrahiert, transfor- 
miert und in das DWH geladen werden. 


2.2.2.2 Berichtserstellung 


Dem Kernprozess der Informationsbeschaffung schließt sich die Berichtserstel- 
lung an. Gegenstand dieses Prozesses ist es, aus den gespeicherten Daten einen 
formalisierten Bericht zu erstellen. Für die Informationserzeugung lassen sich 
Methoden- und Modelldatenbanken nutzen, die eine bessere Auswertung der In- 
formationen erméglichen.!!5 Neben OLAP- und Data Mining-Tools lassen sich 


112 Vgl. Leßweng (2004), S. 41. 

113 Vgl. Abschnitt 2.2. Auf die Bedeutung von Datenbanksystemen als Rückgrat betriebli- 
cher Datenverarbeitung verweisen z. B. Gabriel/Röhrs (2003), S. 357. Eine Übersicht zu 
den Einsatzmöglichkeiten von Datenbanksystemen in verschiedenen Branchen, Institu- 
tionen und Funktionsbereichen liefern Gabriel/Röhrs (1995), S. 8ff. 

114 Zu den Grundlagen und Unterstützungspotenzialen von DMS vgl. Thome/Böhn/Hagn 
(2003), S. 914ff.; Dittmar (2004), S. 291f.; Lehner (2000), S. 339. Als elektronisches 
Dokument wird jede Art von unstrukturierten und strukturierten Informationen verstan- 
den, die als Einheit vorliegen und in einem IS gespeichert sind. Vgl. Lehner (2000), S. 
339f. 


115 Vgl. Göpfert (2002), S. 145. 
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spezialisierte Werkzeuge zur Abfrage und Berichtserstellung nutzen.!!6 Neben 
einfachen Abfragewerkzeugen, mit denen unter Einsatz grafischer Bedienele- 
mente Datenextrakte gebildet werden können, lassen sich Berichtsgeneratoren 
einsetzen. Berichtsgeneratoren zeichnen sich durch eine größere Funktionalität 
aus, indem sie zusätzlich zur inhaltlichen und optischen Anreicherung Gestal- 
tungs- und Berechnungsoptionen zur Verfügung stellen. So genannte Managed 
Query Environments (MOE) lassen sich zum Aufbau und Betrieb eines unter- 
nehmungsweiten Reportings nutzen. Zu den bereitgestellten Features von MQE- 
Tools gehören z. B. eine Administrationsfunktion oder die Bereitstellung einer 
semantischen Schicht, die die Zuordnung von vertrauten Begriffen aus der 
Sprachwelt der Endanwender zu konkreten Datenobjekten ermöglicht.117 

Welche Elemente eines Reports sowie zwischen diesen existierende Be- 
ziehungsstrukturen bei der Berichtserstellung zu beachten sind, lässt sich an- 
hand eines Berichtsmodells verdeutlichen, das in der Abbildung 7 dargestellt 
ist.118 Ziel des in dem Berichtsmodell abgebildeten Pfades ist es, aus einer abs- 
trakten Berichtsvorstellung heraus eine konkrete Berichtsinstanz zu erstellen, 
die dem Informationsbedarf eines Berichtsempfängers oder einer Berichtsemp- 
fängergruppe genügt. 

Wie in Abbildung 7 dargestellt ist, zeichnet sich ein abstrakter Bericht zum 
einen durch den Informationsbedarf (linker Ast), zum anderen durch eine for- 
male Struktur (rechter Ast) aus.!!9 Die formale Struktur eines Berichts ist einer- 
seits durch den Aufbau der Berichtsinhalte andererseits durch die Darstellungs- 
form bzw. das Layout gekennzeichnet, die je nach Präferenz des Berichtsemp- 
fängers eine andere Ausprägung annehmen können. Beim Aufbau, d. h. bei der 
strukturellen Anordnung der Berichtsinhalte, ist Sorge zu tragen, dass die Über- 
sichtlichkeit und Verständlichkeit der berichteten Informationen gewahrt blei- 
ben. KUPPER empfiehlt in diesem Zusammenhang die Verwendung gleicher 
Gliederungsprinzipien sowie die gleichförmige Gestaltung zentraler Berichts- 
elemente, um eine einheitliche Berichtsstruktur zu gewährleisten. !20 

Die Festlegung der Darstellungsform sorgt bei der Generierung eines Reports 
dafür, dass die nachgefragten Informationen nach den Vorstellungen des Emp- 
fängerkreises in dem gewünschten Erscheinungsbild vorliegen. Für die Darstel- 
lung bzw. das Layout der zu berichtenden Informationen stehen drei Varianten 
zur Verfügung. Den rein textuell aufbereiteten Berichtsinformationen, die sich 
mit Hilfe von Tabellen sowie ausformulierten Texten darstellen lassen, stehen 


116 Vgl. Gluchowski (1998), S. 1180ff. 

117 Als Datenobjekte kommen z. B. Datenbanktabellen oder Tabellenattribute in Frage. 

118 Die Ausführungen orientieren sich an dem Vorschlag von BECKER/KÖSTER/SANDMANN, 
die ein entsprechendes Modell vorgelegt haben. Vgl. Becker/Köster/Sandmann (2006), 
S. 504. 

119 Vgl. dazu auch Kemper/Mehanna/Unger (2004), S. 110. 


120 Vgl. Küpper (1997), S. 155. 
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diejenigen Inhalte gegenüber, die sich grafischer Abbildungen wie beispiels- 
weise Kreis-, Balken- oder Säulendarstellungen bedienen.!2! Als dritte Alterna- 
tive kommt eine Mischform in Frage, die zur Visualisierung der Inhalte sowohl 
textuelle als auch grafische Darstellungselemente verwendet. Mit Blick auf das 
zum Einsatz kommende Präsentationsmedium lassen sich Berichte einerseits als 
digitale Dokumente ablegen. Andererseits werden die generierten Berichte auf 
konventionellem Weg als Papierdokumente ausgedruckt. 


Berichtsart 
abstrakt 


wird 
instanziert als 


Bericht 
geprägt durch abstrakt geprägt durch 


wird 
Informations- |konkretisiert in | Auswertungs- Formale 
bedarf dimensionen Struktur 


wird wird 
konkretisiert in konkretisiert in 


bestimmt Fakt 
(Kennzahl) Darstellung 


ist Bestandteil von 


Berichts- ist Bestandteil von 
instanz 


Abbildung 7: Berichtsmodell!22 


Die inhaltliche Komponente eines Berichts wird durch den Informationsbedarf 
bestimmt, der die Nachfrage eines Berichtsempfängers oder einer Berichtsemp- 
fängergruppe nach relevanten und korrekten Informationen widerspiegelt.!23 
Der Informationsbedarf eines Berichtsempfänger(-kreises) konkretisiert sich 
durch die Betrachtungsobjekte bzw. die Dimensionen, die zur Auswertung der 
Kennzahlen dienen. Durch die Verknüpfung der Kennzahlen mit den sie be- 


121 Vgl. Gluchowski (2006), S. 211. 
122 Vgl. Becker/Köster/Sandmann (2006), S. 504. 
123 Zu den Verfahren, die sich zur Bestimmung des Informationsbedarfs nutzen lassen, vgl. 


Krause/Schmitz (2006), S. 351ff. 
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schreibenden Dimensionen entstehen die zu berichtenden Fakten eines Be- 
richts. 124 

Die inhaltlichen Aussagen der zu berichtenden Informationen lassen sich 
darüber hinaus im Hinblick auf ihren Informationsgehalt beschreiben. Dabei ist 
im Vorfeld zu vereinbaren, welcher Sachverhalt im Mittelpunkt der Informati- 
onsversorgung stehen soll. Gegenstand eines Berichts können beispielsweise 
diejenigen Informationen sein, die für die Zwecke des internen und/oder exter- 
nen Berichtswesens benötigt werden.!25 Damit die berichteten Informationen 
einen hohen Aussagehalt enthalten, ist ferner zu entscheiden, in welchem De- 
taillierungsgrad sowie in welcher Genauigkeit die Informationen vorliegen 
müssen. Da aggregierte Berichtsinhalte mit Informationsverlusten verbunden 
sind,!26 ist der Wahl eines geeigneten Aggregationsniveaus, das sich am Infor- 
mationsbedarf des Berichtsempfängers orientiert, besondere Aufmerksamkeit zu 
schenken. 

Werden die Berichtsinhalte in die aus der abstrakten Berichtsvorstellung her- 
aus vorgegebene formale Struktur überführt, so resultiert daraus die Berichtsin- 
stanz und damit die konkrete Ausprägung eines abstrakten Berichts. Neben der 
bereits beschriebenen inhaltlichen sowie formalen Komponente zeichnet sich 
die konkrete Berichtsinstanz dadurch aus, dass in ihr festgelegt ist, welcher 
Mitarbeiter für die Erstellung der Berichtsinstanz verantwortlich ist. Hierbei ist 
anzumerken, dass die Verantwortung für den Berichtsinhalt von der technischen 
Zuständigkeit abweichen kann. Ebenso ist es möglich, dass die berichtserstel- 
lende Person nicht identisch mit dem Berichtsverantwortlichen ist, auch wenn 
diese Arbeitsteilung eher eine Ausnahme im betrieblichen Berichtswesen dar- 
stellt.127 


2.2.2.3 Berichtsdistribution 


Als dritter Teilprozess eines Berichtsprozesses lässt sich die Phase der Be- 
richtsdistribution identifizieren. Alternativ lässt sich dieser Prozess auch als Be- 
richtsverteilung, Berichtsübermittlung oder Berichtsdiffusion bezeichnen.!28 
Gegenstand dieses Prozesses sind alle Aktivitäten, die die zeitnahe und korrekte 
Weiterleitung der erstellten Berichte an den im Vorfeld definierten Empfänger(- 
kreis) fokussieren. Auch die Erläuterungen, die zum Verständnis einzelner Be- 
richtsinhalte beitragen, sind mit dem Bericht zu übermitteln. Die Art der Weiter- 


124 Vgl. Becker/Köster/Sandmann (2006), S. 504. 

125 Zur Unterscheidung in ein internes und externes Berichtswesen vgl. Abschnitt 2.1.2. 
126 Vgl. Sorter (1969), S. 14. 

127 Vgl. Gluchowski (2006), S. 212. 


128 Vgl. Kemper/Mehanna/Unger (2004), S. 111. 
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leitung, d. h. der Kommunikationsweg, hängt dabei von der Wahl des Präsenta- 
tionsmediums ab. 

Liegen die Berichte als elektronische Dokumente vor, erfolgt eine Weiterlei- 
tung der Reports an die jeweiligen Berichtsempfänger über einen digitalen 
Kommunikationsweg. Berichte, die als Papierdokumente ausgedruckt werden, 
lassen sich Berichtsempfängern auf postalischem Weg zukommen oder direkt 
aushändigen. Die digitale Berichtsdistribution lässt sich nach dem Push-Prinzip 
gestalten bzw. betreiben.!29 Beim Push-System erfolgt ein angebotsinduziertes 
Vorgehen, so dass die Informationen automatisch an den Berichtsempfänger 
weitergeleitet werden.!30 Die Erweiterung des Push-Ansatzes wird als Publish 
and Subscribe-Prinzip bezeichnet.!3! Ausgehend von einem Informations- 
bedarfsprofil, das der Anwender erstellen muss, übernimmt das System die ak- 
tive Weiterleitung der Informationen. Eine aktive Informationsdiffusion erfolgt 
z.B. in regelmäßigen Intervallen und/oder bei geänderten Datenkonstellationen, 
die zuvor über entsprechende Ereignisregeln festgelegt werden miissen.!32 

Um die produzierten Berichte auch zu einem späteren Zeitpunkt aufzurufen 
und/oder an die betreffenden Rezipienten weiterzuleiten, müssen die Berichts- 
dokumente bzw. die -dateien kategorisiert bzw. katalogisiert, zwischen- 
gespeichert oder dauerhaft abgelegt werden. Daher spielt im Rahmen der Be- 
richtsdistribution auch die Berichtsverwaltung eine große Rolle. Für die Zwecke 
der Berichtsverwaltung lassen sich beispielsweise Datenbanksysteme oder DMS 
nutzen. Eine Berichtsverwaltung ist zum einen in den Konstellationen bedeut- 
sam, in denen der Berichtsersteller nicht gleichzeitig auch der Berichtsnutzer 
ist. Diese Situation ist beispielsweise gegeben, wenn eine Controlling- 
Abteilung mit der Generierung von Berichten beauftragt ist, die für die Ge- 
schäftsführung bestimmt sind. Zum anderen stiftet die Zwischenspeicherung 
von Berichten Nutzenpotenziale, wenn die Berichtsverarbeitung asynchron ver- 
läuft, d. h., wenn die Berichtsaufnahme zeitversetzt nach der Berichtsdistributi- 
on erfolgt. 


2.2.2.4 Berichtsaufnahme 


Der Teilprozess der Berichtsaufnahme bildet den vorläufigen Abschluss des Be- 
richtsprozesses. Wird ein Bericht nach dem Push-Prinzip per Mail an die Be- 


129 Prinzipiell lässt sich dieses Verfahren auch zur Weiterleitung von Papierdokumenten 
anwenden. Da die vorliegende Arbeit einen IT-gestützten Berichtsprozess fokussiert, 
sind vor allem die IT-gestützten Push-Systeme relevant. 

130 Die Weiterleitung erfolgt meistens regelbasiert. Ein Beispiel für ein Push-System ist ein 
aktives Berichtssystem. 

131 Vgl. Kurz (1999). S. 482ff. 


132 Vgl. Dittmar (2004), S. 300. 
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richtsempfänger weitergeleitet, lässt sich der erfolgreiche Eingang des Berichts 
mit Hilfe einer Empfangsbestätigung quittieren, die ebenfalls per Mail dem Be- 
richtssender zugestellt wird. Eine derartige Empfangsbestätigung lässt sich au- 
tomatisieren oder manuell auslösen. Da die weitergeleiteten Berichte zwischen- 
gespeichert werden können, ist es möglich, dass eine Berichtsaufnahme auch zu 
einem späteren Zeitpunkt nach Eintreffen des Berichts erfolgt. Eine derartige 
Konstellation liegt z. B. vor, wenn die Berichtsdokumente per Mail versendet, 
in einem entsprechenden Berichtsordner auf einem Datei-Server oder in einem 
DMS abgelegt und erst zu einem späteren Zeitpunkt geöffnet werden. 

Werden die Berichte nach ihrer Produktion zunächst beim Berichtsersteller 
zwischengespeichert, erfolgt eine Benachrichtigung, dass der Report „zur Ab- 
holung“ bereit steht. In diesem Fall ist für die Berichtsaufnahme das Pull- 
Prinzip anzuwenden. Während beim Push-Prinzip ein angebotsinduziertes Vor- 
gehen erfolgt, zeichnet sich das Pull-Prinzip dadurch aus, dass der Benutzer ei- 
nen Zugriffsvorgang auslöst, um aus den zur Verfügung stehenden Informati- 
onsquellen die nachgefragten Inhalte zu erhalten.!33 Im Gegensatz zum Push- 
Prinzip muss der Anwender beim Pull-Verfahren wissen, wo sich die benötigten 
Informationen befinden, !3% so dass dem Pull-Verfahren eine nachfrageinduzier- 
te Vorgehensweise zugrunde liegt. Ein solcher Sachverhalt liegt vor, wenn die 
Berichtsnutzer über eine geeignete Schnittstelle auf einen in einem DMS vorge- 
haltenen Report zugreifen, entweder den gesamten Bericht oder nur einen Aus- 
zug des Berichts kopieren und die Kopie auf ihrem lokalen System als separates 
Dokument abspeichern. 

Im Idealfall stimmen die Berichtsinhalte mit dem im Vorfeld definierten In- 
formationsbedarf überein. Wie in Abbildung 6 verdeutlicht ist, existieren zwi- 
schen den Teilprozessen Rücksprünge. Ein Rücksprung vom Teilprozess der 
Berichtsaufnahme zum Teilprozess der Berichtserstellung ist z. B. erforderlich, 
wenn ein Bericht nicht den Anforderungen des Berichtsempfängers entspricht, 
so dass eine Überarbeitung des Berichts notwendig ist. Ursachen für die Nicht- 
Erfüllung der Anforderungen des Berichtsempfängers lassen sich beispielsweise 
in inhaltlichen Divergenzen identifizieren, die dadurch entstehen, dass die in ei- 
nem Bericht enthaltenen Informationen nicht dem Informationsbedarf des Be- 
richtsnutzers entsprechen. Eine weitere Ursache ist in einer fehlerhaften Daten- 
übertragung zu sehen. 

Die Identifizierung der Kernprozesse im Berichtswesen erfolgte mit Blick auf 
die grundsätzliche Möglichkeit zur Gestaltung aller Reporting-Aktivitäten, die 
die effiziente und effektive Transformation der zu berichtenden Geschäfts- und 
Finanzinformationen zum Gegenstand haben. Diese Einschränkung führt dazu, 
dass die von LEßWENG thematisierte, nach der Berichtsaufnahme einsetzende 


133 Eine Ausprägung eines Pull-Systems ist z. B. ein passives Berichtssystem. 


134 Vgl. Lehner (2000), S. 334. 
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Phase der Berichtsdiskussion nicht als Kernprozess des Berichtswesens gewer- 
tet wird.135 Während der Berichtsdiskussion werden die berichteten Inhalte mit 
weiteren Berichtsempfängern und Entscheidern erörtert mit dem Ziel, den Er- 
kenntnisstand der beteiligten Akteure zu erweitern, Entscheidungen vorzuberei- 
ten und zu kontrollieren sowie Aktionen auszulösen.!36 Da es sich hierbei in 
erster Linie um eine kommunikative sowie kognitive Leistung der Berichtsemp- 
fänger handelt, die auf die Interpretation und nicht auf den Fluss sowie die 
Transformation der Informationen ausgerichtet ist, wird die Berichtsdiskussion 
in der vorliegenden Arbeit nicht als Kernprozess im Berichtswesen aufgefasst. 


2.3 Defizite in den Kernprozessen des Berichtswesens 


Nachdem in den vorangehenden Ausführungen sowohl die begrifflichen und 
konzeptionellen Grundlagen als auch die Möglichkeiten einer informations- 
technischen Unterstützung des Berichtswesens thematisiert wurden, hat der vor- 
liegende Abschnitt zum Ziel, Defizite aufzuzeigen, die der Forderung entgegen- 
stehen, ein Reporting zu betreiben, das zukunftsorientierte, entscheidungsrele- 
vante und international vergleichbare Informationen zur Verfügung stellt.!3’ 
Den Vorschlag von LEßBWENG aufgreifend, lassen sich unter dem Oberbegriff 
Defizit sowohl Störungen bzw. Störungsursachen als auch Probleme und 
Schwachstellen verstehen,!38 wobei Probleme und Schwachstellen in Folge von 
Störungen auftreten. Die in Abbildung 8 dargestellte Übersicht dient zur Syste- 
matisierung der Defizite. 

Da bei der Ausführung von Berichtsprozessen die Verarbeitung von Informa- 
tionen im Vordergrund steht, lassen sich zur Gruppierung der Störungsursachen 
die drei Perspektiven der Semiotik heranziehen.!39 Folglich können zweckbe- 
zogene, inhaltsbezogene sowie syntaxbezogene Defizite identifiziert werden. 
Die Störungsursachen wirken sich zum einen auf die Effizienz, zum anderen auf 


135 Vgl. Leßweng (2003a), S. 336. 

136 Siehe dazu die Berichtszwecke in Abschnitt 2.1.3. 

137 Vgl. Böcking (1998), S. 18ff. BECKER/SEIDEL/JANIESCH formulieren in prägnanterer 
Form, dass das Berichtswesen mit der Problematik konfrontiert ist, dass den Managern 
nicht die Informationen für bestmögliche Entscheidungen zur Verfügung stehen. Vgl. 
Becker/Seidel/Janiesch (2008), S. 229. 

138 Vgl. LeBweng (2003), S. 98. 

139 Damit folgt die vorliegende Arbeit dem Vorschlag von Leßweng (2003b), S. 184ff. Zur 


Semiotik vgl. Fußnote 14. 
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die Effektivität des Reportings aus.!40 Der dieser Arbeit zugrunde liegende Ef- 
fizienz- und Effektivitätsbegriff orientiert sich an dem von KUNKELE/SCHAFFER 
im Zusammenhang mit der Budgetkontrolle geprägten Verständnis dieser bei- 
den ökonomischen Zielgrößen.!*! Diesem Verständnis folgend, setzt sich die 
Effektivität des Reportings mit der Frage auseinander, inwieweit der Output 
beim Berichtswesen, d. h. die konkreten Berichte, dem im Vorfeld definierten 
Informationsbedarf des Berichtsempfängers entspricht und zu einer zielgerichte- 
ten Entscheidungsunterstützung beiträgt. Die Effizienz der Informationsverar- 
beitung fokussiert auf die Ressourcen, die für die Erstellung, Auswertung sowie 
Interpretation der Berichtsinformationen aufgewendet werden müssen. Eine ef- 
fiziente Informationsverarbeitung liegt folglich vor, wenn die Verarbeitung der 
Geschäfts- und Finanzinformationen mit minimalen Ressourcen erzielt wird. 
Der wichtigste Kostenblock, der sich negativ auf die Effizienz des Reportings 
auswirkt, sind die Personalkosten, d. h. die Kosten, die dadurch entstehen, dass 
Personen entweder auf der Empfänger- oder auf der Erstellerseite mit der Ver- 
arbeitung der Berichte beschäftigt sind.!42 Darüber hinaus verdeutlicht 
Abbildung 8, welche Kernprozesse des Berichtswesens von dem jeweiligen De- 
fizit am stärksten betroffen sind. 

Abschnitt 2.3.1 widmet sich zunächst den zweckbezogenen Störungen, wäh- 
rend Abschnitt 2.3.2 zu den inhaltsbezogenen Defiziten Stellung nimmt.!43 Ab- 
schnitt 2.3.3 thematisiert syntaxbezogene Defizite, die technisch und/oder Per- 
sonen bedingt sein können. 


140 Generell steht die Effektivität in der Betriebswirtschaftslehre als Grad für die Zielerrei- 
chung und lässt sich folglich als Maß für die Arbeitsleistung bzw. den Output auffassen. 
Vgl. Poluha (2007), S. 74. Die Bedeutung der Effektivität wird in der plakativen Aussa- 
ge „doing the right things“ deutlich. Vgl. z. B. Werner (2002), S. 10. Während die Ef- 
fektivität darauf abzielt, die richtigen Dinge zu tun, geht es bei der Effizienz darum, die 
Dinge, die getan werden müssen, richtig zu tun („doing the things right‘). Als Unterziel 
der Effektivität fokussiert die Effizienz die Ressourcenwirtschaftlichkeit. Zur Gegen- 
überstellung der beiden Begriffe vgl. Poluha (2007), S. 74; Oestereich/Weiss (2008), S. 
419. 

141 Vgl. Künkele/Schäffer (2007), S. 76. 

142 Nach SCHMELZ lagen die Kosten für das Reporting zu Beginn der 90er bei über 30 % 
des Informationsverarbeitungsbudgets. Vgl. Schmelz (1995), S. 72. 

143 Auf die zunehmende Bedeutung der Benutzer- und ale bei der Un- 
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Defizite 


Syntaxbezogen 


Zweckbezogen Inhaltsbezogen - Technisch bedingt 
- Personen bedingt 


Berichtsdistributio Berichtserstellun 

> Berichtsdistribution> g AES 

prozesse 
Berichtsaufnahme Berichtsaufnahme 


Abbildung 8: Ubersicht zu den Problemfeldern bei der Informationsverarbeitung im be- 
trieblichen Berichtswesen 


2.3.1 Zweckbezogene Defizite für die Prozesse „Berichtsdistribution“ und 
„Berichtsaufnahme“ 


Mit der geringen Empfängerorientierung (Abschnitt 2.3.1.1) und der niedrigen 
Informationsaktualität (Abschnitt 2.3.1.2) lassen sich zwei Defizite iden- 
tifizieren, die den Zweckbezug des Reportings beeinflussen. Die im Folgenden 
thematisierten Störungen wirken sich sowohl auf die Berichtsverteilung als 
auch auf die Berichtsaufnahme aus. 


2.3.1.1 Geringe Empfängerorientierung 


Unter den verschiedenen Gefährdungspotenzialen, die der Effektivität und Effi- 
zienz der Informationsverarbeitung im betrieblichen Berichtswesen entgegen- 
wirken, ist die Störungsursache zu erkennen, dass eine einfache und schnelle 
Auswertung der in Form eines Berichts bereitgestellten Geschäfts- und Finanz- 
informationen oftmals verhindert wird.!% Als Hauptgründe für eine nicht emp- 
fängerorientierte Informationsversorgung lassen sich zum einen eine mangelnde 


144 Gestützt wird diese Auffassung auch von BECKER/KOSTER/SANDMANN, deren Einschät- 
zung zufolge der kritische Engpass für ein erfolgreiches Unternehmensreporting nicht in 
der Existenz eines auswertbaren Informationsangebots, sondern in der fehlenden Selek- 
tion, Aufbereitung und Interpretation der Informationen liegt. Vgl. Becker/Köster/ 


Sandmann (2006), S. 502. 
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Relevanz der Berichtsinhalte, zum anderen eine Uberflutung an Informationen 
identifizieren.'!45 Da Manager ungefähr die Hälfte ihrer Arbeitszeit „verschen- 
ken“, um Informationen zu finden, die sie benötigen,!# stellt der schnelle 
Zugriff auf relevante Informationen eine wichtige Anforderung dar, damit Ent- 
scheidungsträger ihre Aufgaben erfüllen können. !#7 

Mit Blick auf die Gefahr der Informationsüberflutung (Information Overload) 
bzw. des Zahlenfriedhofs ist zu konstatieren,!48 dass durch die Vielfalt und die 
Menge der berichteten Informationen eine schnelle kognitive Verarbeitung die- 
ser von den betrieblichen Fach- und Führungskräften nicht geleistet werden 
kann.!49 Die Anforderung, Informationen schnell zu verarbeiten, besitzt eine 
große Bedeutung, da zur betrieblichen Planungs- und Entscheidungsunter- 
stützung vor allem Informationen verarbeitet werden müssen, die unpräzise, va- 
ge und verbal formuliert sind.!50 

Das Problem der Informationsüberflutung wird dadurch gefördert, dass be- 
triebliche Entscheidungsträger zur Befriedigung ihres individuellen Informati- 
onsbedarfs oftmals mit standardisierten, nicht empfängerorientierten Berichten 
versorgt werden, die sich wiederum zu einer rational nicht mehr auswertbaren 
Informationsmenge summieren können.!5! LIEBETRUTH/OTTO kritisieren in die- 
sem Zusammenhang die wachsende Daten- und Kennzahlenflut, zu der insbe- 
sondere der Einsatz von DWH-Systemen beiträgt.!52 Verstärkt wird das Prob- 
lem der Informationsüberflutung durch das so genannte Phänomen der Berichts- 
remanenz, das besagt, dass einmal erstellte Berichte i. d. R. hinsichtlich ihrer 
Aussagekraft bzw. Eignung selten hinterfragt, sondern weiterhin produziert und 
den jeweiligen Empfängern vorgelegt werden. 


145 Vgl. Rechkemmer (1998), S. 380. 

146 Vgl. Besemer (2008), S. 8. 

147 Auf das Problem, dass wichtige Informationen nicht gebündelt in einem Bericht darge- 
stellt, sondern auf mehreren Seiten verteilt werden, verweist Willis (2003), S. 56. 

148 Vgl. Mertens (1999), S. 414; Krause/Schmitz (2006), S. 351. 

149 Vgl. Becker/Seidel/Janiesch (2008), S. 229; Volnhals/Hirsch (2008), S. 50. Wie GABAIX 
ET AL. bemerken, gehen jeder Entscheidungsfindung die Akquisition sowie die Verar- 
beitung von Informationen voraus. Vgl. Gabaix et al. (2006), S. 1042. Zur Diskussion 
verschiedener Auslegungen des Terminus „Information Overload“ vgl. Volnhals/Hirsch 
(2008), S. 51. 

150 Vgl. Werners (1994), S. 1. 

151 Vgl. dazu auch Becker/Köster/Sandmann (2006), S. 503. MERTENS/GRIESE haben in 
diesem Zusammenhang bei einer Stichprobe ermittelt, dass Führungskräfte pro Ar- 
beitstag 23 ausgedruckte Berichte vorgelegt bekommen. Vgl. Mertens/Griese (2002), 
S. 68. 


152 Vgl. Liebetruth/Otto (2006), S. 13. 
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Eine weitere Störungsursache, die zur Informationsüberflutung der Berichts- 
empfänger beiträgt, ist die Granularität der auszuwertenden Informationen.!53 
RECHKEMMER zufolge leidet die Informationsversorgung der Unternehmungs- 
führung, die Überblick verschaffende Informationen nachfragen, an einer Über- 
betonung operativer Aspekte.!54 Will eine Unternehmung jederzeit flexibel auf 
Marktveränderungen reagieren, sind die Führungskräfte hingegen auf strategi- 
sche Informationen angewiesen.!55 KÜNKELE/SCHÄFFER bemerken darüber hin- 
aus, dass eine zu detaillierte Informationsversorgung zu redundanten Daten 
führt, deren Verarbeitung in unnötiger Weise die Ressourcen der Unternehmung 
beansprucht.!56 Den Ausführungen von BLOHM zufolge führt eine übertriebene 
Genauigkeit der berichteten Informationen sowohl zu unnötigen Kosten als 
auch zu Verzögerungen.!5? Gleichzeitig verweisen einige Autoren auf die Ge- 
fahr irrationalen und aktionistischen Verhaltens betrieblicher Entscheidungs- 
träger als Folge einer Informationsüberlastung aufgrund von zu detaillierter In- 
formationen.!58 

Zur Vermeidung der oben beschriebenen Defizite lassen sich z. B. Informati- 
onsbedarfsprofile der Berichtsanwender einsetzen. Derartige Profile, die im 
Vorfeld der Berichtsproduktion erstellt werden müssen, ermöglichen eine be- 
nutzerabhängige Informationsversorgung. Um den Berichtsempfängern zudem 
eine hohe perzeptive Aufnahmefähigkeit der Berichtsinhalte zu ermöglichen, 
empfiehlt GOPFERT die Einhaltung von Gestaltungsregeln, die die Anzahl, den 
Verdichtungsgrad sowie die Übersichtlichkeit der berichteten Informationen 
vorgeben.!59 Diese Erkenntnis wird auch von HIRSCH/PAEFGEN/SCHAIER bestä- 
tigt, die im Rahmen ihrer Feldstudie feststellen, dass die Ist-Gestaltung von 
Monatsberichten von der Soll-Gestaltung der Reports abweicht.!60 Mit Blick 
auf die Wichtigkeit, Berichte möglichst empfängerindividuell zu gestalten, 
schlägt BANGE vor, die Stelle eines Report-Designers einzurichten, dessen Auf- 


153 Vgl. Becker/Seidel/Janiesch (2007), S. 606; Krause/Schmitz (2006), S. 351. Die Granu- 
laritat steht für die Stufe des Verdichtungsgrades von Daten. Vgl. Bauer/Günzel (2004), 
S. 528. 

154 Vgl. Rechkemmer (1998), S. 380. 

155 Vgl. Stock/Büttner (2004), S. 1064. 

156 Vgl. Künkele/Schäffer (2007), S. 78. Auf die Gefahr einer Doppelberichterstattung ver- 
weist auch Blohm (1980), S. 319. 

157 Vgl. Blohm (1980), S. 319. 

158 Zu diesen Autoren gehören beispielsweise CHIA und DÖRNER. Vgl. Chia (1995), 
S. 814f.; Dörner (1989), S. 151 ff. 

159 Vgl. Göpfert (2002), S. 152. In ihrem Beitrag liefert die Autorin weitere Gestaltungsre- 
geln für Berichte. Vgl. Göpfert (2002), S. 152ff. 

160 Vgl. Hirsch/Paefgen/Schaier (2008), S. 331. Als Grund für dieses Defizit geben die Au- 
toren eine mangelnde systematische Kommunikation zwischen den Berichtserstellern 


und -empfängern an. Vgl. Pirsch Paetgen Schauer (2008), S. 332. 
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gabenbereich die Durchführung notwenig gewordener Anpassungen am Inhalt 
sowie am Layout der Berichte umfasst.!6! 

Für einen effektiven Berichtsprozess mit dem Ziel einer empfängerorientier- 
ten Informationsbereitstellung ist darüber hinaus anzustreben, den jeweiligen 
Berichtsempfängern nur diejenigen Informationen zur Verfügung zu stellen, die 
tatsächlich eine Relevanz für diesen Empfängerkreis haben.!62 Die in diesem 
Zusammenhang vom internen Berichtswesen zu bewältigende Herausforderung 
liegt darin, den Berichtsempfängern nicht nur ausgewählte monetäre Kennzah- 
len, sondern alle weiteren, zum Verständnis notwendigen Informationen zu prä- 
sentieren, die z. B. unterschiedliche Unternehmungsbereiche betreffen.!63 Als 
weitere Störungsursache ist das Defizit zu erkennen, dass die berichteten Infor- 
mationen, die aus der Rechnungslegung stammen, vergangenheitsorientiert 
sind,!6* während die Unternehmungsführung auf zukunftsorientierte Berichtsin- 
halte angewiesen ist.!65 

Mit Blick auf die mangelnde Relevanz der Informationen aus dem externern 
Berichtswesen stellen WAGENHOFER und LEV/ZAROWIN fest, dass das Reporting 
von Finanzinformationen in den vergangenen Jahren an Aussagekraft verloren 
hat.!66 In diesem Zusammenhang kritisieren MÜLLER/KLATT/PFITZMEYER, dass 
das Reporting deutscher Konzerne im hohen Maß durch die Fokussierung auf 
finanzielle Größen geprägt ist, die sich den klassischen Bestandteilen eines Jah- 
resabschlusses wie z. B. Bilanz, GuV-Rechnung oder Kapitalflussrechnung ent- 
nehmen lassen.!67 Die Autoren stellen darüber hinaus fest, dass nicht finanzielle 
Größen wie z. B. die Kündigungsrate eine untergeordnete Bedeutung für die 
Steuerung einer Unternehmung zu haben scheinen.!68 

Eine verstärkte Nachfrage nach zusätzlichen Informationen wird sich nach 
WAGENHOFER auch auf die immateriellen Anlagewerte sowie die Werttreiber 
einer Unternehmung richten.!6%° Darüber hinaus prognostizieren XIAO/JONES/ 
LYMER, dass in den kommenden Jahren neben qualitativen Informationen auch 
Informationen nachgefragt werden, die nicht der Wirtschaftsprüfung unterliegen 


161 Vgl. Bange (2004), S. 94. 

162 Vgl. dazu Horvath (2006), S. 601. 

163 Welche Informationen zur Erfüllung der Berichtszwecke von einem betrieblichen Be- 
richtswesen bereitzustellen sind, lässt sich der Aufzählung von GÖPFERT und GÖRICKE/ 
KIRCHHOF entnehmen. Vgl. Göpfert (2002), S. 147; Göricke/Kirchhof (2006), S. 55. 

164 Vgl. Scheer/Bungert (2004), S. 13. 

165 Vgl. Rechkemmer (1998), S. 380. 

166 Vgl. Wagenhofer (2003), S. 263; Lev/Zarowin (1999), S. 383. 

167 Vgl. Müller/Klatt/Pfitzmeyer (2000), S. 355; Gleich et al. (2002), S. 337. Zu dieser Er- 
kenntnis kommen im Rahmen ihrer Auswertung auch Hirsch/Paefgen/Schaier (2008), S. 
328. 

168 Vgl. Müller/Klatt/Pfitzmeyer (2000), S. 355. 


169 Vgl. Wagenhofer (2003), S. 266. 
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und eine Aussage über die zukünftige Entwicklung der berichtenden Unterneh- 
mung liefern.!70 Um der wachsenden Dynamik sowie Komplexität im Unter- 
nehmungsumfeld zu begegnen, sind gemäß der Forderung von GÖPFERT zufolge 
weitere Anstrengungen notwendig, das Berichtswesen im Hinblick auf eine 
stärkere Außen- sowie Zukunftsorientierung auszurichten. !7! 

Festzuhalten ist, dass die Verarbeitung der Informationsmenge mit An- 
strengungen verbunden ist, die wiederum zu Kosten führen. Neben den Lern- 
kosten, die infolge der Nutzung eines IT-Systems entstehen, treten nach WALL 
Arbeitsleid bzw. Opportunitätskosten auf. Diese Kosten entstehen, da Manager 
angesichts der zu verarbeitenden Informationsmenge und knapper Ressourcen 
auf andere Aktivitäten verzichten müssen.!?2 


2.3.1.2 Niedrige Informationsaktualität 


Ausgehend von der Erkenntnis, dass die Aktualität von Informationen einen po- 
sitiven Einfluss auf die Effektivität der Handlungen betrieblicher Entschei- 
dungsträger ausübt, !73 ist in der verzögerten Informationsversorgung eine wei- 
tere Störungsursache für die Effektivität der Verarbeitung berichteter Informati- 
onen zu identifizieren.!74 Diese Einschätzung wird auch von GÖPFERT gestützt. 
Nach ihrer Auffassung stellt die rechtzeitige Verfügbarkeit von Informationen 
einen zentralen Faktor für den Erfolg unternehmerischer Tätigkeit dar.!75 Wer- 
den Informationen nach ihrem Eintreffen mit einer zu großen Verzögerung ver- 
öffentlicht, besteht generell die Gefahr, dass Berichtsinhalte hinsichtlich ihrer 
Aussagekraft an Bedeutung verlieren.!76 HOFFMANN/KUSTERER bemerken in 
diesem Zusammenhang, dass die Informationsbereitstellung (time to informati- 
on) einem wachsenden Zeitdruck ausgesetzt ist.!7”” Während die Unterneh- 
mungsführung auf aktuelle Informationen angewiesen ist, muss konstatiert wer- 
den, dass Berichtsdaten oftmals mit einem beträchtlichen Zeitverzug zur Verfü- 
gung stehen.!78 Im Extremfall liegen die Informationen, beispielsweise bei der 
Nutzung eines DWH-Systems, überhaupt nicht vor.!79 


170 Vgl. Xiao/Jones/Lymer (2002), S. 255. Zu einer identischen Einschätzung kommt auch 
HORVÄTH, nach dessen Auffassung Informationen, die nicht aus dem Rechnungswesen 
stammen, zukünftig an Bedeutung gewinnen werden. Vgl. Horväth (2006), S. 602. 

171 Vgl. Göpfert (2002), S. 156. 

172 Vgl. Wall (2008), S. 85. 

173 Vgl. Chia (1995), S. 821ff. 

174 Vgl. Künkele/Schäffer (2007), S. 78. 

175 Vgl. Göpfert (2002), S. 144. 

176 Vgl. Posselt (1986), S. 78. 

177 Vgl. Hoffmann/Kusterer (1997), S. 49. 

178 Vgl. Rechkemmer (1998), S. 380. 


179 Vgl. Stock/Düsing (2003), S. 188. 
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Werden die Daten eines IS nicht regelmäßig aktualisiert, besteht generell die 
Gefahr, dass diese veralten und somit für eine weitere Verwendung unbrauchbar 
sein können.!80 Ein Beispiel für eine schnell eintretende Alterung von Informa- 
tionen lässt sich in der nachlassenden Aktualität von Aktienkursen feststellen, 
die je nach Erkenntnisstand und Informationsbedarf des Informations- 
empfängers eine nur sehr begrenzte Aussagekraft aufweisen können. Gleichzei- 
tig müssen auch die Informationen, die die Entwicklung eines Aktienkurses be- 
einflussen, in Form eines continuous reporting zeitnah und in regelmäßigen Ab- 
ständen bereitgestellt werden.!8! 

Die Bereitstellung aktueller Informationen ist nicht nur aus dem Blickwinkel 
des internen Berichtswesens von Bedeutung. Auch aus der Perspektive des ex- 
ternen Reportings ist die Veröffentlichung von Informationen über die wirt- 
schaftliche Lage einer Unternehmung, beispielsweise in Form eines Jahres- oder 
Konzernabschlusses, umso nützlicher, je näher sie publiziert werden.!82 Die An- 
forderung, Informationen zur wirtschaftlichen Situation einer Unternehmung 
zeitnah zur Verfügung zu stellen, wird insbesondere von den Akteuren des Ka- 
pitalmarkts geäußert.!83 WEBER ET AL. fügen hinzu, dass insbesondere die Be- 
reitstellung unterjähriger Informationen und von Informationen, die nicht im 
Geschäftsbericht stehen, die Verlässlichkeit und Kontinuität der Unternehmung 
herausstellen.!84 Da den vergangenheitsorientierten Informationen aus dem ex- 
ternen Rechnungswesen der Bezug zu den Geschäftsprozessen fehlt, ist zudem 
das Problemfeld zu identifizieren, dass den Entscheidungsträgern keine aktuel- 
len Informationen zu den Unternehmungsabläufen zur Verfügung stehen.!85 

Ein weiteres Problemfeld, das die Aktualität der berichteten Informationen 
mindern kann, hängt mit der Zunahme der seit Jahren zu beobachtenden Kom- 
plexität des Berichtswesens zusammen. Die Komplexität resultiert aus der Exis- 
tenz paralleler sowie miteinander konkurrierender Informationsströme zwischen 
den berichtenden und den berichtsempfangenden Unternehmungseinheiten, die 
eine zeitnahe IT-gestützte Bereitstellung der Unternehmungszahlen gefähr- 
den.!86 Die Aktualität der Berichte wird dabei in hohem Maß durch die Unter- 
nehmungsstruktur beeinflusst. Liegt beispielsweise ein Konzernverbund vor, so 
sind u. U. Berichte von Hunderten von Tochterunternehmungen, die zudem hin- 


180 Vgl. Leser/Naumann (2007), S. 323. 

181 Vgl. Wagenhofer (2003), S. 265. 

182 Vgl. Schruff/Kayser (2002), S. 349. Die qualitativ hochwertige und fristgerechte Bereit- 
stellung dieser Informationen wird daher oftmals als kritisch betrachtet. Vgl. Hermann/ 
Müller (2008), S. 236. 

183 Vgl. Göricke/Kirchhof (2006), S. 54. 

184 Vgl. Weber et al. (2002), S. 45. 

185 Vgl. Scheer/Bungert (2004), S. 13. 

186 Vgl. Müller/Klatt/Pfitzmeyer (2000), S. 355. Zu den daraus resultierenden Problemfel- 


dern vgl. Göricke/Kirchhof (2006), S. 55. 
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sichtlich ihrer Branche, Region und Rechtsform unterschiedlich ausgeprägt sein 
kénnen,!87 in den entsprechenden IS zusammenzuführen und für ein zeitnahes 
internes sowie externes Reporting aufzubereiten.!88 Potenziert wird dieses Prob- 
lem, wenn sich die Konzernstrukturen häufig ändern, so dass sich ein inhaltli- 
cher und technischer Reportingstandard nicht etablieren kann.!89 Als komplexi- 
tätssteigernd wirkt sich darüber hinaus die Verpflichtung für Unternehmungen 
aus, unterschiedliche Rechnungslegungsvorschriften zur externen Darstellung 
parallel anzuwenden, !9° um auf dem Kapitalmarkt zu operieren oder weil das 
Wirtschaftsrecht am Standort der berichtenden Unternehmung dies erfordert.!9! 


2.3.2 Inhaltsbezogene Defizite für die Prozesse „Berichtserstellung‘“ und 
„Berichtsaufnahme“ 


Die bisher diskutierten Problemfelder erweisen sich insbesondere dann als kri- 
tisch, wenn während der Verarbeitung der berichteten Informationen nicht klar 
ist, um welche Inhalte es sich handelt bzw. welche Bedeutung diese haben. Der- 
artige semantisch bedingte Störungen, die die inhaltliche Dimension eines Be- 
richts betreffen, entstehen, wenn Berichtssender und -empfänger den berichte- 
ten Informationen eine unterschiedliche Bedeutung beimessen.!92 Diese Prob- 
lematik ist zu erwarten, wenn Informationen aus verschiedenen Quellen zu- 
sammengeführt werden müssen, die infolge ihres dezentralen Ursprungs unter- 
schiedlich definiert sind.!93 Betroffen von diesem Defizit sind dabei insbeson- 
dere die Kernprozesse Berichtserstellung und -aufnahme. 
BECKER/KÖSTER/SANDMANN bemerken dazu, dass sich hinter den zur Unter- 
nehmungssteuerung verwendeten Kennzahlen oftmals ein abweichendes indivi- 
duelles Verständnis mit unterschiedlichem Informationsgehalt verbirgt.!94 Prob- 
lematisch ist z. B. die Verwendung unterschiedlicher Währungen und Metriken, 
nicht-normierter Kennzahlen oder Bewertungsmethoden.!95 Liegen beispiels- 
weise einer Bank Jahresabschlüsse kreditsuchender Unternehmungen in unter- 


187 Vgl. Mertens (1999), S. 412. 

188 Siehe dazu auch die Feststellung von Gleich et al. (2002), S. 337. 

189 Vgl. Nutz/StrauB (2002), S. 448. 

190 Zu diesen gehören beispielsweise für deutsche Unternehmungen neben den Rechnungs- 
legungsvorschriften nach HGB auch die Vorschriften nach IFRS und zum Teil US- 
GAAP. Vgl. dazu Göricke/Kirchhof (2006), S. 54. 

191 Vgl. Mertens (1999), S. 412. 

192 Vgl. dazu Kuhn (1990), S.196 

193 Ein Indiz, dass Informationen aus verschiedenen Quellen „zusammengesetzt“ werden 
müssen, ist nach der Auffassung von BLOOM der Einsatz des Tabellenkal- 
kulationsprogramms MICROSOFT EXCEL. Vgl. Bloom (2008), S. 10. 

194 Vgl. Becker/Köster/Sandmann (2006), S. 502. 


195 Vgl. Mertens (1999), S. 412. 
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schiedlichen Rechnungslegungsstandards vor, wird die schnelle Analyse der 
Geschäfts- und Finanzinformationen durch das Ausbleiben zusätzlicher, die 
einzelnen Werte erklärender Informationen erschwert. 196 

Mit Blick auf die Untersuchung von HIRSCH/PAEFGEN/SCHAIER ist in diesem 
Zusammenhang festzuhalten, dass die fehlende Kommentierung von Informati- 
onen — beispielsweise infolge eines Zeitdrucks oder mangelnder Kenntnisse — 
ein wichtiges Problemfeld für die Berichtsempfänger darstellt.!97 Existiert keine 
Übereinkunft hinsichtlich der Bedeutung der zu analysierenden Informationen, 
sind einer automatisierbaren Verarbeitung der Jahresabschlussinformationen 
mit dem Ziel einer schnellen Vergleichbarkeit wichtiger Kennzahlen enge 
Grenzen gesetzt.!98 Um eine Vergleichbarkeit der Jahresabschlüsse von Unter- 
nehmungen zu realisieren, die nach unterschiedlichen Rechnungslegungsstan- 
dards bilanzieren, bleibt als Ausweg oftmals nur die Anwendung aufwendiger 
und manueller Transformationsschritte.199 

Verstärkt wird das Defizit einer ineffektiven semantischen Verarbeitung der 
Berichtsinhalte, wenn für die Berichtsempfänger nicht erkennbar ist, welche 
Ausgangsdaten verarbeitet und welche Transformationsschritte zur Aufberei- 
tung der Inhalte angewendet worden sind.200 Werden Berichte dezentral abge- 
legt, ist oft unklar, welcher Mitarbeiter an welchen Daten zu welchem Zeitpunkt 
Änderungen vorgenommen hat.20! Diese Defizite führen zur Gefahr, dass die 
Informationen, die zwischen unterschiedlichen IS ausgetauscht und anschlie- 
Bend zur Berichtserstellung aufbereitet werden, den in ihnen enthaltenen Zu- 
sammenhang verlieren können.2% Ein solcher wird vermittelt, wenn ein Bericht 
weitere Angaben zu den berichteten Inhalten, zur verwendeten Währung oder 
zum zeitlichen Bezug einer Wertausprägung enthält.203 Ist eine eindeutige in- 
haltliche (Re-)Interpretation der ausgetauschten Informationen nicht oder nur 
unter Inkaufnahme hoher Aufwendungen möglich, lassen sich insbesondere die 


196 Vgl. Kranich/Schmitz (2003), S. 77. 

197 Vgl. Hirsch/Paefgen/Schaier (2008), S. 331. 

198 Welche unterschiedlichen Auslegungen bei der Interpretation einer Kennzahl auftreten 
können, wird am Beispiel der Kennzahl „Umsatz“ deutlich. Siehe dazu das Beispiel bei 
Becker/Köster/Sandmann (2006), S. 503. Die Problematik, die sich aus einer unter- 
schiedlichen Auslegung der verwendeten Begriffe eines Berichts ergeben kann, wird 
auch im Beitrag von BLOHM deutlich. Vgl. Blohm (1980), S. 319. 

199 Vgl. Nutz/StrauB (2002), S. 448. Vgl. dazu auch Abschnitt 2.3.3.2. 

200 Vgl. Becker/Köster/Sandmann (2006), S. 502. Auf das Problem, die Quellen der in ei- 
nem Bericht präsentierten Daten zu identifizieren, verweisen auch Willis/Hannon 
(2005), S. 58. 

201 Vgl. Eckerson/Sherman (2008), S. 24. 

202 Vgl. dazu Meall (2007), S. 73. Auf die Bedeutung, Zusammenhänge zwischen den be- 
richteten Daten abzubilden, verweist Besemer (2008), S. 12. 


203 Vgl. Willis/Hannon (2005), S. 58. 
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Potenziale des World Wide Web (WWW) zur schnellen Verarbeitung der be- 
richteten Informationen nicht vollständig nutzen.2% 

Das oben beschriebene Problem tritt insbesondere dann auf, wenn Berichte 
aus unterschiedlichen Quellen stammen. Obwohl DWH-Systeme die Möglich- 
keit bieten, Berichte aus einem konsistenten und vereinheitlichten Informati- 
onsbestand zu erstellen, ist das betriebliche Berichtswesen i. d. R. dadurch ge- 
kennzeichnet, dass Informationen aus unterschiedlichen Quellen den Führungs- 
kräften getrennt voneinander präsentiert werden.205 In diesem Fall ist es die 
Aufgabe der Geschäftsleitung, aus den verschiedenen Informationsquellen ein 
Gesamtbild zu erstellen, was zur Folge haben kann, dass erneut zweckbezogene 
Defizite auftreten können. 206 

Den Vorschlag von KOCH aufgreifend, lassen sich die semantischen Stö- 
rungsursachen in derivative und originäre Störungen unterscheiden.2°7 Während 
derivate Störungen Folge einer syntaktischen Störung sind, treten originäre Stö- 
rungen unabhängig von einer technisch bedingten, fehlerhaften Verarbeitung 
der Informationen auf. Während in dem vorliegenden Abschnitt originäre se- 
mantische Störungsursachen thematisiert wurden, fokussiert der folgende Ab- 
schnitt Defizite, die zu derivativen semantischen Störungen führen. 


2.3.3 Syntaxbezogene Defizite für alle Teilprozesse des Berichtswesens 


Trotz der Bedeutung des Berichtswesens als wichtiges Instrument für eine er- 
folgreiche Unternehmungssteuerung ist zu bemerken, dass eine effiziente Ver- 
arbeitung von Berichtsinformationen nur in Einzelfällen von den Unternehmun- 
gen betrieben wird.208 Mit Blick auf diesen Aspekt ist zu konstatieren, dass die 
Verarbeitung der berichteten Informationen die Gefahr einer zeitaufwendigen, 
kostenintensiven und fehleranfälligen Tätigkeit birgt.2°9 Derartige syntaxbezo- 
gene Ineffizienzen ergeben sich sowohl im Rahmen des internen als auch exter- 
nen Berichtswesens,?!9 wobei alle Kernprozesse des Berichtswesens von diesen 
Defiziten betroffen sind. 

Wie in den folgenden Ausführungen deutlich wird, lassen sich zwei syntax- 
bezogene Störungsursachen identifizieren, die eine effiziente Ausführung der 
Kernprozesse im Reporting beeinträchtigen. Ausgehend von technisch beding- 
ten Bedrohungspotenzialen, die in Abschnitt 2.3.3.1 thematisiert werden, fokus- 


204 Vgl. Meyer-Pries/Gröner (2002), S. 44. 

205 Vgl. Mertens (1999), S. 406. 

206 Vgl. Abschnitt 2.3.1. 

207 Vgl. Koch (1994), S. 73. 

208 Vgl. Becker/Seidel/Janiesch (2007), S. 605; Becker/Seidel/Janiesch (2008), S. 229. 
209 Vgl. Brown/Willis (2003), S. 70. 


210 Nutz/StrauB (2002), S. 448. 
Alexander Pastwa - 978-3-631-75488-7 


Downloaded from PubFactory at 01/11/2019 04:20:29AM 
via free access 


44 Defizite in den Kernprozessen des Berichtswesens 


siert Abschnitt 2.3.3.2 Defizite, die sich infolge personenbedingter Störungen 
ergeben. 


2.3.3.1 Technisch bedingte Störungen 


Wie andere Anwendungssysteme, die zur Unterstützung eines bestimmten be- 
trieblichen Aufgabenbereichs zum Einsatz kommen, unterliegen auch die Ap- 
plikationen, die für die Zwecke des Reportings bestimmt sind, der Gefahr, dass 
die ihnen vorgehaltenen Daten fehlerhaft oder unzuverlässig sein kénnen.2!! 
Ein Grund für derartige Daten lässt sich in einer syntaktisch fehlerhaften Über- 
tragung und Verknüpfung der berichteten Informationen durch die zum Einsatz 
kommenden IS identifizieren.212 

Aus dem Blickwinkel der IT betrachtet, wird eine effiziente Verknüpfung der 
Informationsquellen aufgrund von unterschiedlichen Betriebssystemplattformen 
und Datenbanksystemen erschwert.2!3 Zwar lassen sich für die Zwecke der Da- 
tenintegration DWH-Systeme nutzen. Jedoch wird die Herausforderung, hetero- 
gene IS zu integrieren, angesichts der Vielzahl der betriebenen DWH- 
Anwendungen auf eine höhere Ebene verlagert.2!4 Die Heterogenität der zum 
Einsatz kommenden Softwaresysteme äußert sich darin, dass sowohl verschie- 
dene Ausprägungen von Datenmodellen bzw. -strukturen als auch diverse 
Zugriffs-, Präsentations- und Austauschformate zur Verarbeitung der Informati- 
onen genutzt werden.2!5 Abbildung 9 liefert eine Zusammenstellung gängiger 
Datenstrukturen, Zugriffs-, Präsentations- und Austauschformate, die in den 
meisten Berichtsanwendungen zum Einsatz kommen. 

Mit Blick auf die Datenstrukturen ist festzustellen, dass in den vergangenen 
Jahrzehnten eine Reihe von Ausprägungen von kommerziellen und nicht- 
kommerziellen Datenbanksystemen entstanden ist, die verschiedene Konzepte 
zur Datenmodellierung unterstützen. Neben den am meisten verbreiteten relati- 
onalen Datenbanksystemen existieren weitere Varianten von Datenbanksyste- 
men, die objektorientierte, objekt-relationale oder multidimensionale Konzepte 


211 Vgl. dazu Becker/Köster/Sandmann (2006), S. 503. 

212 Vgl. Kuhn (1990), S. 196. 

213 Vgl. Mertens (1999), S. 412. Auf die Vielzahl der zum Einsatz kommenden datenhal- 
tenden Systeme zur Verarbeitung von Geschäftsinformationen verweist auch Pandrangi 
(2003). 

214 Auf die Problematik, dass in den Unternehmungen viele DWH-Systeme und unabhängi- 
ge Data Marts betrieben werden — beispielsweise infolge von Unternehmungszusam- 
menschlüssen — verweist Bloom (2008), S. 10. 

215 MEYER-PRIES/GRÖNER bemerken in diesem Zusammenhang, dass beispielsweise der 
Austausch von Abschlussdaten mit dem Problem konfrontiert ist, dass die am Austausch 
beteiligten Partner voneinander abweichende Datensatzstrukturen verwenden können. 


Vgl. Meyer-Pries/Gröner (2002), S. 51. 
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unterstützen. Darüber hinaus werden heute immer noch netzwerkorientierte und 


hierarchische Datenbanksysteme betrieben, die in der Anfangszeit moderner 
Datenverarbeitung entstanden sind.2!6 


Präsentationsformate 


Zugriffs- und 
Präsentationsformate 


*.txt * CSV 


a) a 


Datenmodelle 


Objektorientiertes Datenmodell 
Objektrelationales Datenmodell 
Multidimensionales Datenmodell 
Relationales Datenmodell 
Hierarchisches Datenmodell 
Netzwerkmodell 


Abbildung 9: Heterogenität der Datenstrukturen und Zugriffs-, Präsentations- sowie 
Datenaustauschformate 


Neben der Vielfalt der datenhaltenden Systeme und der von diesen unterstützten 
Konzepte zur Datenverarbeitung ist im gleichen Maße eine Heterogenität an 
Zugriffs-, Präsentations- und Datenaustauschformaten festzustellen, die genutzt 


216 Zu den Varianten eines Netzwerkmodells, hierarchischen, relationalen und objekt- 
orientierten Datenmodells vgl. Rob/Coronel (2007), S. 32ff.; Gabriel/Röhrs (1995), S. 


114ff.; Behme/Ohlendorf (1994), S. 126ff. 
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werden, um aus einem zugrunde liegenden Datenbestand Berichte zu generieren 
und sie einem weiteren Nutzerkreis zu prasentieren.2!7 

Um auf die Daten eines DBS oder DWH-Systems, beispielsweise im Zuge 
der Berichtserstellung, zuzugreifen, werden nicht selten gängige Datenformate 
präferiert, zu denen beispielsweise die HYPERTEXT MARKUP LANGUAGE 
(HTML) oder MICROSOFT EXCEL SPREADSHEET-Dateien (xls) gehören.2!8 Gera- 
de Tabellenkalkulationsprogramme wie MICROSOFT EXCEL stellen die einfachs- 
ten Sammel- und Auswertungswerkzeuge dar,2!9 die beispielsweise über eine 
ODBC-Schnittstelle an ein DBS angebunden werden kénnen.220 HTML wird in 
den gängigen Berichtsanwendungen verwendet, um ein Web-Reporting zu er- 
möglichen. Dies lässt sich bewerkstelligen, indem Berichte mit Hilfe eines BI- 
Tools erstellt, in einem proprietären Format gespeichert und anschließend in ein 
HTML-Dokument transformiert werden. Nachdem der als HTML-Dokument 
vorliegende Report auf einem Web-Server abgelegt wird, lässt sich der Bericht 
über eine URL in einem Web-Browser aufrufen. Dabei werden die Daten aus 
dem angebundenen Quell- bzw. Backendsystem geladen.22! 

Bei den Präsentationsformaten, die ausschließlich zur Darstellung eines Be- 
richts genutzt werden können, lassen sich neben HTML beispielsweise das 
PORTABLE DOCUMENT FORMAT (PDF) sowie sämtliche Office-Formate nut- 
zen.222 Um einen Datenaustausch zwischen einem Quellsystem und einer Ziel- 
Anwendung zu ermöglichen, lassen sich beispielsweise Datenformate wie 
txt, “.csv“, “.mdb“ oder “.xls“ einsetzen.223 Neben den in der Abbildung prä- 
sentierten Formaten existieren für die verschiedenen Anwendungsbereiche dar- 


217 Vgl. dazu auch Hahn (2003), S. 606. 

218 Die Dateiendung “xls“ steht für EXCEL SPREADSHEET. Bei einem EXCEL SPREADSHEET 
handelt es sich um eine Arbeitsmappe, die mit dem Tabellenkalkulationsprogramm 
MICROSOFT EXCEL erstellt wurde. Die Funktionalität, über einen gängigen Web-Browser 
oder über MICROSOFT EXCEL auf einen Datenbestand zuzugreifen, wird heute nahezu 
von allen Datenbanksystemen bereit gestellt. 

219 Vgl. Hahn (2003), S. 605. SCHMITZ zufolge haben im Jahr 2008 65% der mittelständi- 
schen Unternehmungen EXCEL zur Dateneingabe genutzt. Vgl. Schmitz (2008), S. 12. 
BANGE/FRIEDRICH bemerken, dass nur 17 % der im Rahmen ihrer Studie Befragten bei 
der Berichtserstellung und Analyse auf EXCEL verzichten. Vgl. Bange/Friedrich (2008), 
S. 35. 

220 Zu den Vorteilen, die EXCEL für die Zwecke des Reportings bietet, und den Möglichkei- 
ten zur EXCEL-Anbindung von BI-Lösungen und OLAP-Datenbanken vgl. Talarczyk 
(2008), S. 36ff. 

221 Zur WWW-Integration von Datenbanken vgl. z. B. Kleinschmidt/Rank (2002), S. 151ff. 

222 Vgl. dazu Schruff/Kayser (2002), S. 353; Gluchowski/Pastwa (2006), S. 66; Besemer 
(2008), S. 10. 

223 Während die Dateiendung “.txt“ eine einfache Textdatei markiert, stehen die Dateier- 
weiterungen “.csv“ und “.mdb“ für Comma oder Character Separated Values bzw. für 


das Dateiformat MICROSOFT DATABASE. 
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über hinaus weitere proprietäre bzw. herstellerspezifische Formate, die für den 
Datenzugriff, die -präsentation und den -austausch verwendet werden.224 

Als Folge dieser Heterogenität lässt sich das Problem ableiten, dass bei der 
Übermittlung von Daten Ineffizienzen auftreten können.225 Dieses Defizit wird 
verstärkt, wenn unternehmungsexterne Informationen verarbeitet werden müs- 
sen, da sie hinsichtlich ihrer Quelle und Art tendenziell inhomogener sind als 
unternehmungsinterne Informationsquellen.226 Liegen unterschiedliche Formate 
oder Datenstrukturen vor, sind diverse Transformationsverfahren einzusetzen, 
mit deren Hilfe die Datenobjekte samt ihrer Beziehungen und Wertausprägun- 
gen eines IS in die Datenstruktur eines anderen datenhaltenden Systems über- 
führt werden können, das andere Konzepte zur Datenmodellierung und zur Da- 
tenspeicherung unterstützt. Die hier beschriebene Problematik wird verstärkt, 
wenn kein Datenbanksystem eingesetzt und die Daten in hundert- bis tausend- 
fach verstreuten Dateien verwaltet werden.227 

Eine wichtige Voraussetzung, damit sowohl die Transformationsverfahren 
zum Mapping der Datenfelder unterschiedlicher Datenstrukturen angewendet 
als auch die Format- bzw. Medienbrüche beseitigt oder reduziert werden kön- 
nen, liegt in der Bereitstellung entsprechender Schnittstellen. Sind diese nicht 
gegeben, müssen neue Schnittstellen erstellt oder bestehende modifiziert wer- 
den, damit eine automatisierte Datentransformation zwischen den am Aus- 
tauschprozess beteiligten IS erfolgen kann. I. d. R. erweist sich allerdings die 
Erstellung sowie die anschließende Wartung der Systemschnittstellen als eine 
sehr kostenintensive Tatigkeit.228 


2.3.3.2 Personen bedingte Störungen 


Die Existenz von Format- und Medienbrüchen führt zu einem weiteren Prob- 
lem, wenn eine automatisierte Datenübernahme selbst unter hohen Aufwendun- 
gen nicht möglich ist. Die Problematik, die aus der Nutzung vielfältiger, in- 
kompatibler Dateiformate resultieren kann, ist insbesondere dann kritisch, wenn 
neben der Verwendung digitaler Dokumente und Dateien zusätzlich physische 


224 Die dreifachen Punkte in der Abbildung 9 dienen dabei als Platzhalter, um die Vielfalt 
der proprietären Formate anzudeuten, die in dieser Arbeit nicht mehr erwähnt werden. 

225 Vgl. Nutz/Strauß (2002), S. 448. 

226 Vgl. Mertens (1999), S. 413. MERTENS zufolge liegt in der mangelnden Anbindung von 
externen qualitativen Informationen die Ursache für die geringe Akzeptanz von Mana- 
gement-Informationssystemen. Vgl. Mertens (1999), S. 414. 

227 Vgl. Talarczyk (2008), S. 36. 


228 Vgl. Meyer-Pries/Gröner (2002), S. 51. 
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Medien genutzt werden.229 Ein solches Problem ist z. B. gegeben, wenn die 
auszutauschenden Informationen in ausgedruckten Berichtsdokumenten enthal- 
ten sind und anschließend manuell in ein IS zur Speicherung und/oder weiteren 
Bearbeitung übertragen werden müssen.230 In diesem Zusammenhang ist zu 
konstatieren, dass fehlerhafte oder unzuverlässige Daten oftmals infolge einer 
manuellen Dateneingabe auftreten.23! 

Tippfehler führen beispielsweise dazu, dass die in ein Datenbanksystem ein- 
gepflegten Werte entweder falsch eingegeben sind oder bereits vorhanden sein 
können. Problematisch ist darüber hinaus, wenn die Daten über verschiedene 
Kanäle in ein oder gar mehrere IS gelangen. Neben den digitalen Kommunika- 
tionswegen wie beispielsweise Web-Formulare oder E-Mail führen nach wie 
vor klassische Kommunikationsmedien, zu denen z. B. das Telefon oder der 
Briefverkehr gehören, zur Aufnahme und Übertragung fehlerhafter oder unzu- 
verlässiger Daten in die zur Datenhaltung vorgesehenen IS. Neben den tech- 
nisch bedingten Problemfeldern lassen sich daher Personen bedingte Störungs- 
ursachen identifizieren, die die Effizienz der Kernprozesse im Reporting ge- 
fährden. 

Neben den in Abschnitt 2.3.3.1 bereits identifizierten Defiziten als Folge ei- 
ner technisch bedingten fehlerhaften und unzuverlässigen Datentransformation 
verweisen SAMTLEBEN/STADLBAUER/HESS auf weitere, die aus einer manuellen 
Dateneingabe resultieren können. Im Fokus stehen dabei mögliche Kosten- und 
Zeitnachteile.232 Kostennachteile ergeben sich dadurch, dass für die manuelle 
Datenübernahme Personal beauftragt werden muss. Diese Erkenntnis wird auch 
von MÜLLER/KLATT/PFITZMEYER gestützt, die in ihrem Beitrag bemerken, dass 
insbesondere der geringe Automatisierungsgrad bei der Verarbeitung von Be- 
richtsinformationen ein weiterer Hinderungsgrund für eine effiziente Berichter- 
stattung ist, da viele Ressourcen für die manuellen Abstimmungs- und Korrek- 
turarbeiten an den Informationen aufgewendet werden müssen, die nicht zur 
Wertschöpfung beitragen.233 Mit Blick auf den Zeitaspekt ist zu konstatieren, 
dass der manuelle, zeitintensive Import der Daten dazu führen kann, dass der 


229 Nach WILLIS sind insbesondere Banken mit dem Problem konfrontiert, in einem manu- 
ellen Prozess Informationen aus Papierdokumenten, die wiederum aus verschiedenen 
Quellen stammen, zusammenzuführen. Vgl. Willis (2003), S. 58. 

230 Vgl. Göricke/Kirchhof (2006), S. 56. 

231 Vgl. Eckerson/Sherman (2008), S. 24; Leser/Naumann (2007), S. 322; Samtleben/ 
Stadlbauer/Hess (2006), S. 88. 

232 Vgl. Samtleben/Stadlbauer/Hess (2006), S. 87. 

233 Vgl. Müller/Klatt/Pfitzmeyer (2000), S. 356; Hannon (2006), S. 60. In diesem Zusam- 
menhang ist zu bemerken, dass Mitarbeiter bis zu zwei Drittel ihrer Arbeitszeit für die 
Kontrolle, Korrektur und Aufbereitung der Daten und Informationen aufwenden müs- 


sen. Vgl. Köthner (2006), S. 6. 
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Anspruch der Berichtsempfänger hinsichtlich einer zeitnahen Informationsver- 
sorgung nicht erfüllt wird.234 

Ferner muss eine manuelle Mehrfacherfassung der Daten häufig erfolgen, 
falls es nicht gelingt, mit aufwendigen Transformations- oder Konvertierungs- 
verfahren eine automatisierte Datenübernahme zu erreichen.235 Wie MEYER- 
PRIES/GRÖNER bemerken, ist die Mehrfacherfassung von Daten der internen und 
externen Berichterstattung insbesondere ein Problem für Konzerne, Verbände, 
Analysten und Finanzinstitute.23° Obwohl viele der kommerziell angebotenen 
Softwaresysteme und -werkzeuge, die für Reporting-Zwecke eingesetzt werden, 
gängige Datenformate unterstützen, kann es ferner erforderlich sein, die Daten 
in ein anderes Format zu transformieren oder zumindest manuell anzupassen, 
damit eine anschließende Auswertung der Inhalte erfolgen kann. Wegen der 
Vielfalt der Datenstrukturen und Datenformate ist die manuelle Manipulation 
der Daten ebenfalls mit der Gefahr verbunden, dass die Daten verloren gehen 
oder falsch aufbereitet werden.237 

Dass Datenfehler sowie redundante Datensätze in den Berichtssystemen auf- 
treten, hängt nicht nur mit menschlicher Nachlässigkeit zusammen. In gleichem 
Maße kann auch die automatisierte, maschinen- sowie computergestützte Erfas- 
sung von Daten beispielsweise durch den Einsatz von Scannern, Importroutinen 
und/oder Texterkennungsprogrammen zu einer reduzierten Datenqualität füh- 
ren.238 LESER/NAUMANN weisen darauf hin, dass im Allgemeinen fehlerbehafte- 
te Messungen einerseits mit dem Ziel der Kostenersparnis bewusst in Kauf ge- 
nommen werden, andererseits sich vor dem Hintergrund technischer Restriktio- 
nen nicht verhindern lassen.239 

Ein weiteres Problemfeld, das zu personenbedingten Störungen beitragen 
kann, ist die Nutzung von Tabellenkalkulationsprogrammen wie MICROSOFT 
EXCEL.240 Probleme entstehen, wenn in den Arbeitsblättern Makros verwendet 
werden, die von einem Mitarbeiter entwickelt wurden, der die Unternehmung 
verlassen hat.24! Werden die entsprechenden Arbeitsblätter zwischen den Mit- 


234 Vgl. Samtleben/Stadlbauer/Hess (2006), S. 87f. 

235 Vgl. Nutz/Strauß (2002), S. 448; Göricke/Kirchhof (2006), S. 55. 

236 Vgl. Meyer-Pries/Gröner (2002), S. 45. 

237 Vgl. Becker/Köster/Sandmann (2006), S. 502. 

238 Texterkennungsprogramme werden auch als Optical Character Recognition-Programme 
(OCR-Programme) bezeichnet. OCR-Programme bieten die Möglichkeit, Texte einzus- 
cannen und anschließend mit Hilfe von Textverarbeitungsprogrammen weiterzu- 
verarbeiten. Vgl. Hansen/Neumann (2005), S. 364. 

239 Vgl. Leser/Naumann (2007), S. 322. 

240 Eine Übersicht über Problemfelder von MICROSOFT EXCEL liefert Grabowski (2008), S. 
23. 


241 Vgl. Eckerson/Sherman (2008), S. 24. 
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arbeitern ausgetauscht und weiterverwendet,242 ist oft Unkenntnis hinsichtlich 
der Funktionalität sowie Erweiterungsmöglichkeiten der Makros zu beobach- 
ten.24 Letztlich führt dieses nicht vorhandene Wissen zu weiteren Kosten- und 
Zeitnachteilen. 


2.4 Zusammenfassung und kritische Würdigung 


Das vorliegende Kapitel rückte die Prozessunterstützung im betrieblichen Be- 
richtswesen in den Vordergrund. Zur inhaltlichen Fundierung fokussierte Ab- 
schnitt 2.1 zunächst die begrifflichen und konzeptionellen Grundlagen des Re- 
portings sowie die Zwecke, die mit dem Berichtswesen in Verbindung stehen. 
Abschnitt 2.2 präsentierte mit den Berichtssystemen eine Klasse von IS zur Un- 
terstützung der Kernprozesse im Berichtswesen. Aus den Ausführungen des 
Abschnitts 2.3 wurde deutlich, dass sich eine Reihe von Defiziten identifizieren 
lässt, die die Effektivität sowie die Effizienz der Kernprozesse beeinträchtigen. 

Als zusammenfassendes Ergebnis der Ausführungen dieses Kapitels wird das 
Berichtswesen einer Unternehmung als Gesamtheit aller Personen, Prozesse und 
IS aufgefasst, die zur Erzeugung, Aufbereitung, Übermittlung und Auswertung 
von formalisierten Berichten beitragen. Aus dieser Zieldefinition wird deutlich, 
dass das dieser Arbeit zugrunde liegende Verständnis des Berichtswesens über 
die Vorstellung von BECKER/SEIDEL/JANIESCH hinausgeht, da für die Autoren 
ausschließlich die innerbetrieblichen Entscheidungsträger als Rezipienten der 
Berichte in Frage kommen.?* Um die Informationsverarbeitung zu verbessern, 
erfolgt in den Berichten i. d. R. eine Visualisierung der vermittelten Inhalte.245 
Zur informationstechnischen Unterstützung des Berichtswesens kommen Be- 
richtssysteme zum Einsatz. 

Vor dem Hintergrund der in Abbildung 2 präsentierten Einordnung des Be- 
richtswesens nach GÖPFERT ist zu konstatieren, dass der dieser Arbeit zugrunde 
liegende Definitionsvorschlag der weiten Begriffsauslegung folgt. Kritisch an 
der engen Auslegung nach BLOHM ist zu werten, dass das Berichtswesen ledig- 
lich als Instrument zur Informationsübermittlung verstanden wird.246 Auch die 
von HORVÄTH erweiterte Sichtweise, bei der das Berichtswesen mit der Infor- 
mationsübermittlung und -produktion gleichgesetzt wird, ist als eine zu enge 
Perspektive zu beurteilen.247 


242 Nach KÖTHNER verschicken 82 Prozent von 500 befragten Unternehmungen EXCEL- 
Dateien per Mail, um Planungsprozesse durchzuführen. Vgl. Köthner (2008), S. 26. 

243 Vgl. Eckerson/Sherman (2008), S. 24. 

244 Vgl. Becker/Seidel/Janiesch (2007), S. 607. 

245 Vgl. Kemper/Mehanna/Unger (2004), S. 110. 

246 Siehe dazu die Ausführungen in Abschnitt 2.1.1. 


247 Vgl. Abschnitt 2.1.1. 
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Darüber hinaus wird in dieser Arbeit in Abgrenzung zu HORVATH die Auffas- 
sung vertreten, dass das Berichtswesen nicht nur auf das Top-Management son- 
dern ebenfalls auf Berichtsempfanger auszurichten ist, die sich auf allen Hierar- 
chiestufen einer Unternehmung befinden.248 Die Ausweitung des Empfanger- 
kreises impliziert, dass in einem Report nicht nur Geschäfts- und Finanzinfor- 
mationen präsentiert werden, die in aggregierter bzw. konsolidierter Form v- 
orliegen — z. B. infolge einer Abfrage auf das DWH, das einem Berichtssystem 
zugrunde liegt.249 In analoger Weise lassen sich auch disaggregierte Informati- 
onen bzw. Detaildaten, die in transaktionsorientierten Systemen verarbeitet 
werden, in einem Bericht aufnehmen.250 Als Ausprägung einer derartigen In- 
formation lässt sich das Beispiel eines Buchungssatzes anführen. 

Vor dem Hintergrund der in Abschnitt 2.1.3 thematisierten Berichtszwecke 
ist ferner zu konstatieren, dass der von HORVÄTH propagierte alleinige Be- 
richtszweck, die ergebniszielorientierte Planung und Kontrolle zu unterstützen, 
eine zu enge Sichtweise darstellt und daher ebenfalls in dieser Arbeit abgelehnt 
wird.25! In gleicher Weise, wie die Planung und Kontrolle von Bedeutung sind, 
fokussiert das betriebliche Berichtswesen ebenfalls die Dokumentation von Er- 
eignissen und die Auslösung von Aktivitäten. 

Die enge Auslegung des Berichtswesens sowie die Fokussierung auf das Ma- 
nagement als ausschließliche Berichtsempfängergruppe haben dazu geführt, 
dass die enge Interpretation des Reportings von einer Mehrheit der Autoren kri- 
tisiert wurde und auch in dieser Arbeit abgelehnt wird.252 Stattdessen wird in 
dieser Arbeit die Auffassung vertreten, dass die beim Berichtswesen anfallen- 
den Informationsflüsse die Gestaltung aller Kernprozesse im Berichtswesen er- 
fordern, um dem Informationsbedarf der Berichtsempfänger zu genügen. Hierzu 
ließen sich mit der Informationsbeschaffung, Berichtserstellung, Berichtsdistri- 
bution und Berichtsaufnahme vier Kernprozesse identifizieren. 

Mit Blick auf die in Abschnitt 2.3 präsentierten Defizite bei der Ausführung 
der Berichtsprozesse ist aus der Perspektive der Wirtschaftsinformatik die Frage 
von Interesse, welche aktuell diskutierten Konzepte und Technologien dazu bei- 
tragen, die Kernprozesse im betrieblichen Berichtswesen effektiver und effi- 
zienter zu gestalten und zu betreiben. Ein potenzieller, in der Literatur aktuell 
diskutierter Ansatz liegt beispielsweise mit dem Konzept einer Serviceorientier- 
ten Architektur (SOA) vor. 


248 Vgl. Bange (2004), S. 94; Leßweng (2003), S. 66. 

249 Derartige Informationen werden i. d. R. von Entscheidungsträgern der mittleren und hö- 
heren Managementebene nachgefragt. 

250 Neben einem hohen Detaillierungsgrad zeichnen sich derartige Daten durch eine hohe 
Aktualität und Genauigkeit aus. Vgl. Hansen/Neumann (2005), S. 528. 

251 Vgl. dazu auch Koch (1994), S. 60. 


252 Vgl. Göpfert (2002), S. 144. 
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3 Serviceorientierte Architekturen (SOA) als innovatives Konzept 
für eine integrierte Informationsverarbeitung 


Dass die effiziente und effektive Verarbeitung von Informationen durch den 
Einsatz geeigneter IS einen wichtigen Erfolgsfaktor für eine Unternehmung dar- 
stellt, ist anerkanntes Gedankengut in der Betriebswirtschaftslehre und Wirt- 
schaftsinformatik.253 Dieser Zusammenhang lässt sich insbesondere ver- 
deutlichen, wenn man die Unternehmung als informationsverarbeitendes Sys- 
tem modelliert.25 Sowohl einzelne betriebliche Funktionen als auch die Durch- 
führung gesamter unternehmungsinterner sowie -übergreifender Geschäfts- 
prozesse hängen von den Informationen sowie den IS ab, die eine teil- oder 
vollautomatisierte Informationsverarbeitung ermöglichen sollen. Die zur Verfü- 
gung stehende Informationstechnik (IT) wird dabei häufig mit dem Ziel einge- 
setzt, die Wirtschaftlichkeit und Produktivität einer Unternehmung zu verbes- 
sern.253 

Als Teil eines IS sind den Anwendungssystemen, die zur Unterstützung der 
Informationsverarbeitung innerhalb einer geeigneten Anwendungsarchitektur 
betrieben werden, sowie der Anwendungsarchitektur selbst eine besondere Be- 
achtung zu schenken, da die Entscheidung für eine bestimmte Applikationsar- 
chitektur maßgeblich die Aufwendungen für die Entwicklung, die Einführung, 
den Betrieb sowie die Wartung der Anwendungssysteme beeinflusst.256 Da die 
Geschäftsprozesse von der IT sowie den IT-Anwendungen unterstützt bzw. erst 
ermöglicht werden,257 ist in diesem Zusammenhang zu beachten, dass Ände- 
rungen an den Geschäftsprozessen zu Modifikationen an der gesamten IS- 
Architektur einer Unternehmung führen müssen,?58 die sich wiederum in ent- 
sprechenden Aufwendungen niederschlagen.259 Die Herausforderung, integrier- 


253 Vgl. Gabriel/Beier (2003), S. 22; Gluchowski/Gabriel/Dittmar (2007), S. 27f.; Hansen/ 
Neumann (2005), S. 16ff.; Laudon/Laudon/Schoder (2006), S. 27ff.; Horvath (2006), 
S. 664ff. 

254 Vgl. Gabriel/Rohrs (1995), S. 23ff. 

255 Vgl. Holtschke/Heier/Hummel (2009), S. 1. 

256 Vgl. Müller (2007a), S. 89. Die Begriffe Anwendungsarchitektur, Applikations- 
architektur und Anwendungssystemarchitektur werden im Folgenden synonym verwen- 
det. 

257 Vgl. Klempt/Werners (2009), S. 311; Mantel/Schissler (2002), S. 171. Im Rahmen einer 
empirischen Analyse verdeutlichen Beimborn et al., dass die IT einen Einfluss auf die 
Gesamtprozessleistung aufweist. Vgl. BEIMBORN ET AL. (2006), S. 332ff. 

258 Vgl. hierzu auch Heuser/Lacher/Perlmann (2007), S. 21. 

259 Zur Abgrenzung der Begriffe Anwendungsarchitektur und IS-Architektur vgl. Abschnitt 


3.2.1. 
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te und interoperable IS-Architekturen zu schaffen, hat einen hohen Stellenwert, 
da das Zusammenspiel von Anwendungssystemen in einer IS-Architektur einen 
Schlüsselfaktor für die Gestaltung einer integrierten Informationsverarbeitung 
darstellt, wie sie beispielsweise im Rahmen des Supply Chain Management- 
Ansatzes gefordert wird. 

Aus der Perspektive der Wirtschaftsinformatik „als Vermittler zwischen den 
betriebswirtschaftlichen Anforderungen der Unternehmen und den technischen 
Möglichkeiten der Informationsverarbeitung‘“260 interessiert in diesem Zusam- 
menhang die Frage, auf welche Weise betriebliche Anwendungssysteme einer- 
seits kosteneffizient gestaltet, andererseits auf Basis einer geeigneten IS- 
Architektur integriert werden können, um eine wirtschaftliche Informationsver- 
arbeitung zu ermöglichen.26! Neben den unterschiedlichen Ansätzen zur Ent- 
wicklung von Anwendungssystemen existieren eine Fülle von Standards, Kon- 
zepten und Techniken, die sich in den einzelnen Phasen des Gestaltungsprozes- 
ses von Anwendungssystemen nutzen lassen.262 Trotz der Existenz verschiede- 
ner Lösungsansätze, die in den vergangenen Jahrzehnten zur Gestaltung integ- 
rierter Anwendungssysteme vorgeschlagen wurden,263 handelt es sich hierbei 
um ein Forschungsfeld, das nach wie vor eine hohe Relevanz in der Wirt- 
schaftsinformatik besitzt.264 

Von allen Konzepten, die sich mit der Frage beschäftigen, wie sich Anwen- 
dungssysteme und IS-Architekturen zur Unterstützung einer integrierten Infor- 
mationsverarbeitung gestalten und/oder integrieren lassen, wird in den aktuellen 
Beiträgen unter dem Begriff Serviceorientierte Architektur bzw. Service Orien- 
ted Architecture (SOA) ein Ansatz diskutiert, der seit seiner begrifflichen Prä- 
gung eine besonders hohe Beachtung erfährt.265 In der wissenschaftlichen Aus- 


260 Thome (1998), S. 964. Zum Verständnis der Wirtschaftsinformatik vgl. auch Laudon/ 
Laudon/Schoder (2006), S. 44. 

261 Vgl. Glöckle (2007), S. 8 und 18; Heinrich/Klier/Bewernik (2006), S. 158. THOME 
spricht in diesem Zusammenhang von einem integrierten System als „die Endstufe bei 
der Entwicklung wirtschaftlicher Informationsverarbeitungslösungen“. Thome (2007), 
S. 655. 

262 Vgl. Holten (2003), S. 41. 

263 Einen Überblick über verschiedene Generationen von Integrationslösungen präsentieren 
Samtleben/Stadibauer/Hess (2006), S. 88ff.; Hansen/Neumann (2005), S. 529ff.; Kink 
(2008), S. 359. 

264 Diese Einschätzung wird auch von AIER/SCHÖNHERR geteilt, nach deren Auffassung die 
Integration und Interoperabilität der Infrastrukturen der von einer Unternehmung einge- 
setzten IT ein weiterhin ungelöstes Problemfeld darstelle. Vgl. Aier/Schönherr (2006), 
S. 188. 

265 Vgl. Eymann/Winter (2008), S. 70; Mattern (2003), S. 34; Klesse/Wortmann/Schelp 
(2005), S. 259; Durst/Daum (2007), S. 18. Den Ausführungen von LIEBHART zufolge, 
wurde der Begriff einer SOA im Jahr 1996 von der IT-Marktforschungsunternehmung 


GARTNER RESEARCH geprägt. Vgl. Liebhart (2007 
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einandersetzung sowie mit Blick auf die bisherigen Erfahrungsberichte erwei- 
sen sich die Erwartungshaltungen und die Einschätzungen zu SOA als vielfäl- 
tig. Der Anspruch des vorliegenden Kapitels richtet sich daher auf das Ziel, die 
in der Literatur existierenden Aspekte zum verhältnismäßig jungen Forschungs- 
gebiet der SOA zu einem integrierten Verständnis zusammenzuführen. 

Der Aufbau des vorliegenden Kapitels gliedert sich wie folgt: Abschnitt 3.1 
widmet sich zunächst einer Zustandsbeschreibung der betrieblichen Applikati- 
onslandschaft, die heute in vielen Unternehmungen vorherrscht. In diesem Zu- 
sammenhang werden die Treiber vorgestellt, die in jüngster Zeit zu einem 
wachsenden Interesse an SOA geführt haben. Das Ziel von Abschnitt 3.2 liegt 
darin, die in den diversen Beiträgen thematisierten Merkmale einer SOA zu drei 
Sichtweisen zusammenzufassen. Im Anschluss widmet sich Abschnitt 3.3 der 
Frage, was unter dem Begriff des Softwareservices bzw. des Softwaredienstes 
zu verstehen ist und welche Prinzipien zur Entwicklung und Nutzung derartiger 
Dienste eingehalten werden müssen. Mit Blick auf die Implementierungsmög- 
lichkeiten einer SOA thematisiert Abschnitt 3.4 die Technologie der Web Ser- 
vices.266 Aufbauend auf diesen Grundlagen wird in Abschnitt 3.5 ein integrier- 
tes Begriffsverständnis einer SOA erarbeitet. 


3.1 Integrierte Informationsverarbeitung im Kontext aktueller SOA- 
Treiber 


Die Erwartungen, die mit dem Betrieb einer SOA in der Literatur geäußert wer- 
den, richten sich auf die Minimierung der Defizite heutiger Anwendungs- 
systeme, die eine effiziente und effektive integrierte Informationsverarbeitung 
verhindern. Ausgehend vom Begriff der integrierten Informationsverarbeitung 
in Abschnitt 3.1.1 thematisiert Abschnitt 3 den Zustand der betrieblichen An- 
wendungssysteme, wie er aktuell in vielen Unternehmungen zu beobachten ist. 
Daraufhin setzt sich Abschnitt 3.1.3 mit der Fragestellung auseinander, welche 
Treiber identifiziert werden können, die in der heutigen Unternehmenspraxis 
eine integrierte Informationsverarbeitung gefährden und damit maßgeblich zu 
einem wachsenden Interesse an SOA beigetragen haben. 


3.1.1 Begriff der integrierten Informationsverarbeitung 


In Anlehnung an GABRIEL/RÖHRS ist unter Informationsverarbeitung jeder Vor- 
gang zu verstehen, der die Erfassung, Speicherung, Übertragung oder Trans- 


266 In der Literatur werden neben der Schreibweise „Web Service“ auch die Varianten 
„Webservice“, „WebService“, „Web service“ und „Web-Service‘“ verwendet. Vor dem 
Hintergrund ihres verbreiteten Gebrauchs orientieren sich die folgenden Ausführungen 


an der Schreibweise „Web Service“. 
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formation von Daten zum Gegenstand hat.267 Da diese Vorgänge sequentiell ab- 
laufen können, wird der daraus resultierende Prozess als Informationsverarbei- 
tungsprozess bezeichnet. Die verschiedenen Fragestellungen, die sich mit der 
Integration der Informationsverarbeitung auseinandersetzen, thematisieren im 
Kern, inwieweit sich die verschiedenen Informationsverarbeitungsvorgänge und 
-ressourcen koordinieren bzw. zusammenfügen lassen. Dabei liegt diesen Fra- 
gestellungen ein Integrationsbegriff zugrunde, der aus der Perspektive der Wirt- 
schaftsinformatik für die Verknüpfung von Menschen, Aufgaben und Technik 
steht.268 Ziel der Integrationsbemühungen ist es, die unternehmungsbedingten 
Funktions-, Prozess- und Abteilungsgrenzen aufzuheben oder zumindest zu- 
rückzudrängen. In diesem Zusammenhang lassen sich verschiedene Perspekti- 
ven bzw. Typen einer integrierten Informationsverarbeitung unterscheiden. Im 
Fokus stehen dabei Integrationsgegenstände, die sich aus einer technischen Per- 
spektive betrachten lassen.269 Abbildung 10 liefert eine Übersicht über häufig 
genannte Integrationsdimensionen.27° 

Vor dem Hintergrund der Aufbauorganisation einer Unternehmung lässt sich 
eine horizontale Integration von einer vertikalen Integration unterscheiden. Im 
Fokus dieses Integrationstyps stehen die betrieblichen Funktionen, die von bzw. 
in einer Unternehmung erbracht werden. Während eine horizontale Integration 
die funktionsübergreifende Verknüpfung der Administrations- und Dispositi- 
onssysteme entlang der betrieblichen Wertschöpfungskette zum Gegenstand 
hat, umfasst die vertikale Integration die Datenversorgung der Planungs- und 
Kontrollsysteme aus den Administrations- und Dispositionssystemen.27! 

Mit Blick auf die Integrationsreichweite steht der Möglichkeit einer innerbe- 
trieblichen Integration die Variante einer zwischenbetrieblichen Integration ge- 
gentiber.272 Im Gegensatz zur innerbetrieblichen Integration erfolgt bei der zwi- 


267 Vgl. Gabriel/Röhrs (1995), S. 4. 

268 Vgl. Herden et al. (2006), S. 11. Welche Bedeutung diese drei Faktoren z. B. für die 
Zwecke einer integrierten Datenverarbeitung im Finanz- und Rechnungswesen haben, 
verdeutlicht Heinrich (2002), S. 45. AIER/WINTER bemerken in diesem Zusammenhang, 
dass die Wirtschaftsinformatik als interdisziplinäres Forschungsfach prädestiniert ist für 
Integrationsfragestellungen. Vgl. Aier/Winter (2009), S. 1. 

269 Wie HERDEN ET AL. ausführen, lässt sich mit Blick auf den interdisziplinären Charakter 
der Wirtschaftsinformatik die Integration von IS nicht nur aus einer technischen sondern 
auch aus einer organisatorischen Perspektive betrachten. Vgl. Herden et al. (2006), S. 
11. 

270 Eine erweiterte Auflistung der in Abbildung 10 präsentierten Integrationsdimensionen 
liefern Fink/Schneidereit/Voß (2005), S. 212. 

271 Vgl. Herden et al. (2006), S. 15. 


272 Vgl. Herden et al. (2006), S. 16. 
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schenbetrieblichen Integration die Verknüpfung der Informationsverarbeitungs- 
ressourcen über Unternehmungsgrenzen hinweg. 


Integrationsdimensionen Ausprägungen 


Vertikal 


Integrationsrichtung Horizontal 


Integrationsreichweite Innerbetrieblich Zwischenbetrieblich 


Integrationsobjekt Geräte Prozesse Funktionen Daten 
Automatisierungsgrad Vollautomatisch Teilautomatisch 
Informationstypen Daten Texte Grafiken Video Audio 


Abbildung 10: Ausgewählte Integrationsdimensionen 


Eine weitere gebräuchliche Unterscheidung trennt die Integrationstypen Vor- 
gangsintegration bzw. Prozessintegration, Datenintegration, Funktionsinte- 
gration und Geräteintegration. Bei der Prozessintegration wird angestrebt, Pro- 
zesse oder Vorgangsketten zu verknüpfen und ihre automatisierte Ausführung 
zu ermöglichen. Bei der Datenintegration ist es das Ziel, Datenbestände anwen- 
dungsübergreifend bereitzustellen.273 In Analogie zur Prozessintegration fokus- 
siert die Funktionsintegration die Koordination der zum Einsatz kommenden 
Funktionen. Funktionen, die in einem Programm definiert werden können, 
transformieren Eingangsdaten in Ausgangsdaten nach einem vorgegeben Sche- 
ma.274 Bei der Geräteintegration wird hingegen die Fragestellung thematisiert, 
wie sich eine gemeinsame Nutzung von Hardware-Komponenten koordinieren 
und durchführen lässt. 

Ein weiteres wichtiges Abgrenzungsmerkmal der verschiedenen Integrati- 
onsmöglichkeiten ist der Automatisierungsgrad. In diesem Zusammenhang lässt 


273 Vgl. Ließmann/Kaufmann/Schmitzer (1999), S. 12. 

274 Bei einem Programm handelt es sich um eine Abfolge von Anweisungen, die die Verar- 
beitung von Daten auf einem Rechner steuern. Vgl. Laudon/Laudon/Schoder (2006), S. 
35. Da in einem Programm Funktionen verwendet werden können, ist die Funktionsin- 
tegration gleichzeitig Basis für eine Programmintegration. Abzugrenzen ist eine Funkti- 
on von einer Aufgabe. Funktionen lassen sich in einem Programm vollautomatisiert aus- 
führen, während eine Aufgabe von einem Subjekt ausgeführt wird und sich entweder gar 
nicht oder nur teilweise automatisieren lässt. Eine partielle Automatisierung ist gegeben, 
wenn Teilaufgaben durch den Einsatz von Programmen unterstützt werden. Vgl. Herden 


et al. (2006), S. 16. 
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sich eine vollautomatische von einer teilautomatischen Integration unterschei- 
den. Eine vollautomatische Informationsverarbeitung ist gegeben, wenn sich 
verschiedene Aktivitäten eines Prozesses gegenseitig anstoßen, ohne dass eine 
menschliche Interaktion erfolgt. Im Vergleich zu dieser Integrationsart liegt bei 
einer teilautomatischen Integration eine menschliche Interaktion bei der Aus- 
führung eines Prozesses vor. 

Neben den bisher präsentierten Integrationsformen können auch die ver- 
schiedenen Informationstypen Gegenstand einer integrierten Informations- 
verarbeitung sein. Eine integrierte Informationsverarbeitung ist beispielsweise 
gegeben, wenn verschiedene Informationsdarstellungen und Medien, wie for- 
matierte Daten, Texte, Grafiken, Video- und Audiosequenzen, aufeinander ab- 
gestimmt werden, um z. B. einen bestimmten Sachverhalt mit Hilfe eines aussa- 
gekräftigen Berichts zu vermitteln.275 


3.1.2 Betriebliche Anwendungssysteme — State of the Art 


Allgemein ist eine mangelnde Ausrichtung der IT an die Gesamtunternehmung 
zu bemerken, die zu einer Reihe von Problemfeldern geführt hat.276 Wie 
MELZER ET AL. ausführen, sind viele Unternehmungen derzeit mit IT-Systemen 
konfrontiert, die sich als historisch gewachsene Systeme in den vergangenen 
Jahren isoliert von anderen Systemen entwickelt haben und folglich heute als so 
genannte „Insellösungen“ betrieben werden.?77 Als begriffliche Alternativen für 
derartige Systeme finden sich die Bezeichnungen ,,Applikationssilos“278 und 
„IT-Säulen“2?79. Zur Entwicklung dieser Systeme wurden in den vergangenen 
Jahren hohe Investitionen aufgewendet.280 

Ursprünglich als Systeme zur Abwicklung von kleinen sowie speziellen Auf- 
gaben entwickelt und auf die verschiedenen Fachbereiche einer Unternehmung 
zugeschnitten, haben diese Systeme im Laufe ihrer Nutzung an Funktionalität 
und Komplexität hinzu gewonnen.28! Vor dem Hintergrund der Restriktion, 
dass in den vergangenen Jahren — ebenso wenig wie in der heutigen Praxis — 
keine Softwaresysteme als Gesamtpaket verfügbar waren, die alle Funktionen 


275 Die integrierte Verarbeitung unterschiedlicher Informationsdarstellungen und Medien 
wird als Multimedia bezeichnet. Vgl. Hansen/Neumann (2005), S. 7. 

276 Vgl. Gericke/Stutz (2006), S. 362. 

277 Vgl. Melzer et al. (2007), S. 28. 

278 Vgl. Höß et al. (2007), S. 39; Schelp/Winter (2007), S. 43. 

279 Vgl. Melzer et al. (2007), S. 28. 

280 Vgl. Kossmann/Leymann (2004), S. 117. 

281 Vgl. Samtleben/Stadlbauer/Hess (2006), S. 87. Komplexität lässt sich als Ergebnis tech- 
nischer und geschäftlicher Entscheidungen auffassen, die zu einer negativen Entwick- 
lung der Applikationsarchitektur beigetragen haben. Zur Auflistung einiger komplexi- 


tätssteigernder Faktoren vgl. Gimnich (2007), S. 69. 
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einer Unternehmung abdeckten, wurde entweder für jede zu unterstützende 
Funktion ein separates Softwaresystem eingesetzt oder die betreffende Funktion 
in dem bereits existierenden System individuell entwickelt.282 Auf diese Weise 
ließen sich die Informationsverarbeitungsaufgaben in den verschiedenen Ge- 
schäftsfunktionen einer Unternehmung wie z.B. Beschaffung, Vertrieb und 
Marketing, Fertigung und Produktion, Finanz- und Rechnungswesen sowie Per- 
sonalwesen IT-gestützt bewältigen.283 Während bei der Auswahl sowie der 
Entwicklung von Software das Interesse vieler IT-Abteilungen auf die Funktio- 
nalität und die Architektur des Systems gerichtet war, spielte die Integration 
dieser Anwendungen zunächst eine untergeordnete Rolle.284 

Die heute zu beobachtende Konsequenz aus der skizzierten Entwicklung ist, 
dass in den Unternehmungen sehr viele spezialisierte Softwaresysteme betrie- 
ben werden,285 die nicht nur instransparent, sondern auch redundant sind.286 Die 
Softwaresysteme zeichnen sich dabei nicht nur durch ihren spezifischen An- 
wendungsbereich aus, für den sie gestaltet wurden,28? sondern auch durch die 
Heterogenität der bereitgestellten Schnittstellen und der verwendeten Program- 
miersprachen. Hierbei stehen „neue“ Programmiersprachen, die wie beispiels- 
weise im Fall von Java oder C++ objektorientierte Konzepte unterstützen, „älte- 
re“ Programmiersprachen gegenüber, die den ersten Sprachgenerationen zuzu- 
ordnen sind.288 Auch wenn letztere insbesondere zum Betrieb der Altsysteme 
notwendig sind,289 haben sie heute nur eine untergeordnete Relevanz für eine 
produktive, an den Qualitätsstandards ausgerichtete Softwareentwicklung.290 
Die Heterogenität der Anwendungssysteme stützt sich nicht nur auf die ver- 
wendeten proprietären Softwaresysteme, sondern auch auf die verschiedenen 
Hardwareplattformen, die wie die Softwaresysteme von verschiedenen kom- 


282 Vgl. Kossmann/Leymann (2004), S. 117. 

283 Zu den Geschäftsfunktionen vgl. Laudon/Laudon/Schoder (2006), S. 37. 

284 Vgl. Samtleben/Stadlbauer/Hess (2006), S. 87. 

285 Vgl. Klesse/Wortmann/Schelp (2005), S. 259; Kossmann/Leymann (2004), S. 117; 
Samtleben/Stadlbauer/Hess (2006), S. 87. 

286 Vgl. Gericke/Stutz (2006), S. 362. 

287 In Abhängigkeit vom Verwendungszweck lassen sich die Kategorien Systemsoftware, 
Entwicklungssoftware und Anwendungssoftware unterscheiden. Vgl. Hansen/Neumann 
(2005), S. 163f. 

288 Eine Übersicht zu den Programmiersprachen verschiedener Generationen präsentieren 
Fink/Schneidereit/Voß (2005), S. 32ff. Einen Überblick über die derzeit nachgefragtes- 
ten Programmiersprachen liefert der Programmiersprachenpopularitätsindex, der von 
der Unternehmung TIOBE veröffentlicht wird. Vgl. Tiobe (2008). 

289 Zu den Eigenschaften von Altsystemen vgl. Abschnitt 3.1.3.1. 

290 Die wichtigsten Qualitätsmerkmale von Software werden von POMBERGER/BLASCHEK 


diskutiert. Vgl. Pomberger/Blaschek (1993), S. 9ff. 
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merziellen und nichtkommerziellen Herstellern angeboten werden.29! Nach der 
Einschätzung von KLESSE/WORTMANN/SCHELP ist trotz der ansteigenden 
Verbreitung und Verwendung von Standardsoftware auch in den kommenden 
Jahren nicht zu erwarten, dass die heterogenen Systemlandschaften abgelöst 
werden.292 

Im Ergebnis hat die bisher beschriebene Entwicklung in den vergangenen 
Jahren zu einer vertikal organisierten IT-Landschaft geführt, die, wie in der 
Abbildung 11 zu erkennen ist, aus einer Vielzahl isolierter Anwendungssysteme 
besteht.293 Derartige Anwendungssysteme verfiigen tiber einen eigenen Daten- 
bestand, der sich mit Hilfe eines vorgegebenen Vorrats an Funktionen verarbei- 
ten lässt. Ferner zeichnen sich isolierte Anwendungssysteme durch eine eigene 
Prozesssteuerung aus. Zur Prozesssteuerung stellen die Systeme ihren Anwen- 
dern eine eigene Benutzungsschnittstelle in Form eines Klienten (Client) oder 
einer grafischen Benutzungsoberfläche, die auch als Graphical User Interface 
(GUTI) bezeichnet wird, zur Verfügung. 


Applikation 1 Applikation 2 Applikation n 


|| lee ae 
ALZAS AS 


TETTI 


Prozesse 


Funktionen 


Daten 


Abbildung 11: Applikationssilos2%4 


291 Den Einsatz veralteter und teilweise proprietärer Technologien bemängeln z. B. Höß et 
al. (2007), S. 39. 

292 Vgl. Klesse/Wortmann/Schelp (2005), S. 259. 

293 Vgl. Rieks (2006), S. 6. 


294 In Anlehnung an Melzer et al. (2007), S 
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Um betriebswirtschaftliche Konzepte wie z. B. das Supply Chain Management 
umzusetzen, ist es erforderlich, die heterogenen Anwendungssysteme zu kop- 
peln und mit den Geschäftsprozessen zu verkntipfen.295 Mit Hilfe des Einsatzes 
integrierter betrieblicher Anwendungssysteme wird dabei das Ziel verfolgt, or- 
ganisatorische und informationstechnische Verbundeffekte zu realisieren.2?6 
Die mit diesem Ziel durchgeführten Integrationsprojekte hatten zur Folge, dass 
die Applikationen gewachsen sind und durch die gestiegene Anzahl an Funkti- 
onen eine beträchtliche Komplexität erreicht haben.297 Darüber hinaus verfügen 
die heutigen Anwendungssysteme über eine hohe Anzahl an Schnittstellen zu 
anderen Applikationen, wodurch vielfältige Abhängigkeitsbeziehungen resultie- 
ren, die zu einem Gebilde geführt haben, das heute auch als „Spaghetti- 
Architektur“ bezeichnet wird.298 Im Ergebnis ist festzuhalten, dass die histo- 
risch gewachsenen IT-Architekturen nicht nur die Komplexitat,299 sondern auch 
die Unübersichtlichkeit der Gesamtarchitektur einer Unternehmung forciert ha- 
ben. 300 


3.1.3 Treiber für das Interesse an SOA 


Als Folge der im vorherigen Abschnitt skizzierten Entwicklung lassen sich De- 
fizite identifizieren, die derzeit ein Problemfeld in den IT-Abteilungen vieler 
Unternehmungen darstellen. Die zu erläuternden Problembereiche lieferten in 
den vergangenen Jahren den Ausgangspunkt für die wissenschaftliche Ausei- 
nandersetzung mit neuen fachlichen Konzepten und technischen Ansätzen zur 
Entwicklung sowie zur Integration von Anwendungssystemen. Der prominen- 
teste Vertreter unter diesen Vorschlägen wird derzeit unter dem Themenfeld 
SOA diskutiert. 

Die Ausführungen dieses Abschnitts verfolgen das Ziel, die in der Literatur 
viel zitierte Bedeutung von SOA anhand geeigneter Einflussfaktoren zu syste- 
matisieren. Als Ausgangspunkt hierfür können die Treiber zu Rate gezogen 
werden, die im Zusammenhang mit dem Einsatz einer SOA in den diversen Li- 
teraturbeiträgen genannt wurden. Zur Identifizierung der relevanten Treiber für 
das Interesse an SOA wurde eine Analyse ausgewählter Beiträge durchgeführt, 
deren Ergebnisse überblicksartig in Abbildung 12 dargestellt sind. Um die Er- 


295 Vgl. Holten (2003), S. 41. 

296 Vgl. Müller/Hess (2006), S. 109. 

297 Dem Verständnis von HANSEN/NEUMANN folgend, steht der Komplexitätsbegriff für den 
Umfang der exakten Beschreibung aller Einzelheiten eines IS und ihrer Abhängigkeiten 
voneinander. Vgl. Hansen/Neumann (2005), S. 169. 

298 Vgl. Holtschke/Heier/Hummel (2009), S. 109. 

299 Vgl. Schelp (2007), S. 144. 


300 Vgl. Holtschke/Heier/Hummel (2009), S. 109. 
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gebnisse in einer anschaulichen Weise zu präsentieren, wurden die Treiber 
stichwortartig zusammengefasst und den jeweiligen Autoren zugeordnet. 


Beimborn/Weitzel Inner- und zwischenbetriebliche . sci 
(2003) Integration von Anwendungssystemen Automatischer Datenaustausch Prozessautomatisierung 
Flexibilisierung von 
go ee Wiederverwendbarkeit Geschaftsprozessen / Unterstutzung 
g neuer Geschaftsprozesse 
HessiHummNVoß Flexibilisierung von Geschäftsprozessen / Unterstützung 
Hohe Kosten des IT-Betriebs neuer Geschällsprazesse 


Mangelhafte Flexibilität Probleme bei notwendigen 
beim Umsetzen neuer Hohe Kosten des IT- technischen 

Geschäfts- bzw. Betriebs Modemisierungen in der IT- 
(2006) Baschafspionzese Marktanforderungen Architektur 


a: Möglichst gute Prozessunterstützung durch die IT Flexible Reaktion auf Prozessänderungen 
Leyking/ZiemanniLoos | Engere Verknüpfung der IT-Systeme mit betrieblichen : 
(2006) Funktionen und Geschäftsprozessen Flexiblere und bessere Steuerung der IT-Systeme 
. : A . Flexibilisierung von 
Righteriiatenisciwey Hohe Kosten des IT-Betriebs EIRNDIE Reamon auf Ander igen) Geschäftsprozessen / Unterstützung 
(2006) der Unternehmensstruktur 
neuer Geschaftsprozesse 


Abbildung 12: Literaturauswertung zu den Treibern einer SOA 


HeutschifLeugner! | Unzulangliche bzw. fehlende 
Österie Unterstützung bestehender 


Aus den Nennungen lassen sich zwei Treiberkategorien identifizieren, die das 
Interesse an SOA forciert haben. Während Abschnitt 3.1.3.1 die Kosten der 
Systementwicklung und der Systemintegration in den Vordergrund rückt, wird 
in Abschnitt 3.1.3.2 die mangelnde IT-Unterstützung von Geschäftsprozessen 
als zweite Treiberkategorie thematisiert.3°! 


3.1.3.1 Kosten des IT-Betriebs 


Vor dem Hintergrund sinkender IT-Budgets besitzt die Anforderung, die Kosten 
für die Entwicklung, den Betrieb und die Wartung heterogener Anwendungs- 
systeme zu reduzieren, eine wichtige Herausforderung für die IT-Abteilungen 
der Unternehmungen.?% Mit Blick auf die in Abschnitt 3 beschriebenen Eigen- 
schaften einer funktional angeordneten IT-Landschaft einer Unternehmung sind 
einem kostengünstigen Betrieb der IT-Landschaft einer Unternehmung enge 


301 Dass die Erwartungshaltung an den Aufbau einer SOA sich auf die Flexibilität der Ge- 
schäftsprozesse und die Reduktion von IT-Kosten richtet, wird ebenfalls bei 
HUMM/Juwia deutlich. Vgl. Humm/Juwig (2006), S. 1. 

302 Vgl. Hofmann (2003), S. 27. Da Unternehmungen nach LANKES ET AL. ohnehin einem 
wachsenden Kostendruck ausgesetzt sind, gewinnt diese Anforderung umso mehr an 


Bedeutung. Vgl. Lankes et al. (2008), S. 12. 
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Grenzen gesetzt.303 Darüber hinaus wird gefordert, die in Abschnitt 3 themati- 
sierte Heterogenität in Bezug auf die eingesetzte Software und Hardware sowie 
die implementierten Schnittstellen zu überwinden. Hinweise für diese Feststel- 
lung lassen sich in den Nennungen der Abbildung 12 entnehmen. Aus den Nen- 
nungen geht hervor, dass die „hohen Kosten des IT-Betriebs“, die „flexiblere 
und bessere Steuerung der IT-Systeme“, die „inner- und zwischenbetriebliche 
Integration von Anwendungssystemen“ sowie die „Probleme bei notwendigen 
technischen Modernisierungen in der IT-Architektur“ wichtige Treiber darstel- 
len, die einen effizienten Betrieb der IT-Landschaft einer Unternehmung ge- 
fährden und sich daher zu einer Treiberkategorie zusammenfassen lassen.304 

Wie Höß ET AL. in diesem Zusammenhang bemerken, fehlt es den bestehen- 
den Systemen an Offenheit und Flexibilität, um die an sie gestellten Anforde- 
rungen zu bewältigen.305 Flexibilität kann dabei als die Eigenschaft eines Sys- 
tems verstanden werden, auf sich abzeichnende Änderungen im System oder im 
Umfeld des Systems ex ante in einer sinnvollen Weise reagieren zu können.?06 
Damit richtet sich Flexibilität auf die Fähigkeit einer Applikation, geänderte 
Bedarfe zur Informationsverarbeitung zu befriedigen oder sich sonstigen Ver- 
änderungen im Umfeld der Applikationslandschaft anzupassen.3°7 

Einen gewichtigen Kostenblock, der aus der Inflexibilität der betriebenen IS 
resultiert, bilden die Wartungskosten. In der Softwareentwicklung besitzt die 
Wartungsphase eine wichtige Bedeutung, da sie nicht nur den längsten, sondern 
i.d. R. auch den teuersten Abschnitt im Lebenszyklus eines Softwaresystems 
repräsentiert.308 Abbildung 13 verdeutlicht, dass die Kosten, die über den ge- 
samten Lebenszyklus eines Softwaresystems für die Wartung anfallen, in den 
vergangenen 50 Jahren stetig gewachsen sind. Im Vergleich zu den Kosten, die 
für die reine Softwareentwicklung sowie für die Beschaffung und Benutzung 
der Hardware entstehen, machen die Wartungskosten heute mehr als 70% der 
Gesamtkosten aus. Gleichzeitig ist festzustellen, dass Softwareprojekte mit ei- 
nem oft zu geringen Wartungsbudget auskommen müssen.309 


303 Vgl. Holtschke/Heier/Hummel (2009), S. 109. 

304 Zum Begriff der IT-Architektur vgl. die Ausführungen in Abschnitt 3.1.3.2. 

305 Vgl. Höß et al. (2007), S. 39. 

306 Vgl. Müller (2007a), S. 91; Schelp (2007), S. 147. 

307 Vgl. Müller (2007a), S. 91. Abzugrenzen ist der Flexibilitätsbegriff vom Terminus der 
Geschwindigkeit, der auf die Reaktionsfähigkeit der betrieblichen Anwendungssysteme 
abzielt, nicht vorhergesehenen Entwicklungen bzw. Änderungen ohne eine signifikante 
zeitliche Verzögerung begegnen zu können. Vgl. Schelp (2007), S. 147. 

308 Vgl. Gluchowski/Gabriel/Chamoni (1997), S. 132. 


309 Vgl. Gimnich (2007), S. 69. 
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Abbildung 13: Steigende Wartungskosten3!0 


Neben den Kosten infolge inflexibler IS ergeben sich weitere Aufwendungen, 
die bei der Integration der betrieblichen Anwendungssysteme anfallen.3!! Mit 
Blick auf die Notwendigkeit, i. d. R. eine Vielzahl von Applikationen zu integ- 
rieren, liegt ein wichtiger Kostenblock, der im Rahmen eines derartigen Projekts 
aufzuwenden ist, in der Wartung und Weiterentwicklung der Schnittstellen der 
zu integrierenden Systeme.3!2 Als Ursache für dieses Defizit ist zu bemerken, 
dass mit Blick auf die Vielfalt der zur Verfügung stehenden Kommunikations- 
mechanismen bzw. -protokolle und modellierten Datenformate fehlende Stan- 
dards eine kosteneffiziente Wartung und Wiederverwendbarkeit der Schnittstel- 
len verhindert haben.3!3 


310 In Anlehnung an Mas y Parareda/Pizka (2007), S. 60. 

3ll Dass die Integration betrieblicher Anwendungssysteme heute einen bedeutenden Kos- 
tenfaktor darstellt, wird an den Kosten deutlich, die Fortune-1000-Unternehmungen für 
derartige Projekte aufwenden. Nach KAIB investierten diese jährlich mehr als 100 Mrd. 
US $ für Integrationsprojekte. Vgl. Kaib (2002), S. 1. 

312 Vgl. hierzu Höß et al. (2007), S. 40. Wird ein klassisches sequentielles Vorgehensmo- 
dell zugrunde gelegt, bildet die Wartung 1. d. R. die abschließende Phase des Software- 
projekts. Ihr gehen die Phasen Problemanalyse, Entwurf, Implementierung, Funktions- 
und Leistungsüberprüfung, Installation und Abnahme voraus. Vgl. Gabriel/Röhrs 
(1995), S. 122ff. Auf die Bedeutung einer effizienten und effektiven Schnittstellenges- 
taltung für Unternehmungen verweisen auch Hirsch/Sorg (2006), S. 428. 


313 Vgl. Rieks (2006), S. 6. 
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Dass die Wartung der Schnittstellen eine ressourcenintensive Aufgabe dar- 
stellt, wird auch durch die Einschätzung von KLESSE/WORTMANN/SCHELP ge- 
stützt, die darauf verweisen, dass 35 bis 60% des IT-Budgets für die Erstellung 
und Wartung der Schnittstellen verbraucht werden.3!4 Weiterhin beträgt der 
Aufwand für das Schnittstellendesign und die -implementierung ca. 30% der 
Zeit bei Softwareentwicklungsprojekten.3!5 Als großes Problem erweist sich in 
diesem Zusammenhang die Existenz so genannter Punkt-zu-Punkt-Schnitt- 
stellen, die erstellt werden, um bedarfsweise bzw. ad hoc bestehende mit neuen 
Anwendungen zu verbinden.3!6 Das Ergebnis einer derartigen Vorgehensweise 
mündet in ein komplexes Anwendungsgeflecht und in schwer wartbare Abhän- 
gigkeiten. 

Weitere Kosten, die zur Bewältigung der Heterogenität der Anwendungssys- 
teme auftreten, lassen sich am besten am Beispiel der Altsysteme verdeutlichen, 
die auch als Legacy-Systeme bezeichnet werden. Auch wenn sich bisher keine 
allgemeine und etablierte Definition durchgesetzt hat, was unter einem Legacy- 
System zu verstehen ist,3!7 herrscht Einigkeit, dass sich derartige Systeme als 
alte bzw. gewachsene Softwaresysteme auffassen lassen, deren Entwicklung 
viele Jahre zurtickliegt.3!8 Oftmals kommen im Rahmen von Altanwendungen 
auf Mainframes installierte, abteilungsübergreifende oder gar unternehmungs- 
weite Datenbanksysteme zum Einsatz.3!9 Zur weiteren Präzisierung, was unter 
einem „alten“ Softwaresystem zu verstehen ist, werden in der vorliegenden Ar- 
beit alle Softwaresysteme als Legacy-Systeme bezeichnet, die vor der Verbrei- 
tung der objektorientierten Programmierung entwickelt wurden.320 Eine weitere 
Konkretisierung dieser Auslegung erfolgt bei LIEBHART, dessen Auffassung 
nach Legacy-Systeme in Assembler oder einer früheren Version einer Drittge- 
nerationssprache wie COBOL oder ALGOL geschrieben wurden.32! 

Aufgrund ihres monolithischen und heterogenen Charakters ist eine Verknüp- 
fung derartiger IS mit anderen Applikationen zudem nur unter Inanspruchnah- 


314 Vgl. Klesse/Wortmann/Schelp (2005), S. 259. 

315 Vgl. Klesse/Wortmann/Schelp (2005), S. 259. 

316 Vgl. Gimnich (2007), S. 69. 

317 Vgl. Liebhart (2007), S. 182. 

318 Vgl. Mas y Parareda/Pizka (2007), S. 60. 

319 Siehe hierzu das Beispiel bei Sunyaev et al. (2006), S. 31. 

320 Diese Abgrenzung folgt der Sichtweise von SOMMERVILLE. Vgl. Sommerville (2001), S. 
595. Eine Zäsur bildet in diesem Zusammenhang der Beginn der 1990-er Jahre, als C++ 
sich als dominierende Sprache der objektorientierten Programmierung durchgesetzt hat. 
Zur Geschichte der objektorientierten Softwareentwicklung vgl. Balzert (2000), S. 7ff. 

32l Der Autor liefert darüber hinaus weitere „Indizien“ zur begrifflichen Präzisierung eines 
Legacy-Systems. Vgl. Liebhart (2007), S. 182. Das Akronym COBOL steht für „Com- 
mon Business Oriented Language“. ALGOL stellt eine Abkürzung für die Programmier- 


sprache „Algorithmic Language“ dar. 
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me hoher Aufwendungen zu bewerkstelligen.322 Auch die Auslagerung von 
Prozessaktivitäten und damit die Einbindung externer IT-Dienstleister und de- 
ren Services führen beim Betrieb eines monolithischen Systems zu hohen Auf- 
wendungen.323 Da Legacy-Systeme sich i. d. R. aus einem Zusammenspiel di- 
verser Anwendungssysteme und Programme zusammensetzen, ist davon auszu- 
gehen, dass diese Programme erst im Lauf der Nutzung eines Altsystems hinzu- 
gefügt oder geändert wurden. Dabei ist ebenfalls anzunehmen, dass bei der An- 
derung bzw. Modifikation der Legacy-Systeme eine Reihe von Anwendern und 
Entwicklern partizipiert haben, deren individuelle Anforderungen sowie Fach- 
kenntnisse zu einer permanenten, unkontrollierten Weiterentwicklung der Sys- 
teme geführt haben. 

Darüber hinaus ist zu konstatieren, dass notwendig gewordene Anpassungen 
und Veränderungen an den Systemen, die unter Einsatz verschiedener, z. T. ver- 
alteter Programmiersprachen mit unterschiedlichen Versionen durchgeführt 
wurden, oftmals ungenügend oder unzureichend dokumentiert wurden.324 Die- 
ses Problem erweist sich als umso gravierender, je mehr unterschiedliche Pro- 
grammierstile sowie Konzepte des Software Engineering bei der (Weiter-) 
Entwicklung eines derartigen Systems zur Anwendung kamen. In vielen Fällen 
ist bei der Verwendung von Legacy-Systemen nicht nur ein Mangel an Doku- 
mentation des Quellcodes, sondern auch eine nicht vorhandene Spezifikation 
der Systeme festzustellen. Ebenso sind i. d. R. bei dem Betrieb von Legacy- 
Systemen Geschäftsabläufe sowie Geschäftsbeschreibungen an keiner Stelle 
festgehalten oder auffindbar. In diesem Zusammenhang erweist es sich als wei- 
tere Schwierigkeit, Mitarbeiter zu finden, die über entsprechende Programmier- 
kenntnisse sowie eine Ausbildung im Umgang mit den eingesetzten Technolo- 
gien, Programmiersprachen und Hardware-Systemen eines Legacy-Systems ver- 
fiigen.325 

Neben den Kosten, die sich aus der Wartung der Schnittstellen sowie aus ei- 
ner Verwendung unterschiedlicher Programmiersprachen ergeben, sind darüber 
hinaus Aufwendungen zu berücksichtigen, die für die Hardware derartiger An- 
wendungssysteme anfallen. Hierbei ist festzustellen, dass Legacy-Systeme 
i.d. R. auf Hardware-Komponenten von Großrechnern basieren, die in den 


322 Monolithische Anwendungssysteme zeichnen sich dadurch aus, dass ihre System- 
komponenten eine untrennbare Einheit bilden und sich daher nur schwer bzw. unwirt- 
schaftlich sowie unter Reduzierung der Softwarequalität herauslösen oder ersetzen las- 
sen. I. d. R. setzen Monolithen auf einem proprietären Betriebssystem auf. Monolithi- 
sche Anwendungssysteme wurden auf einem zentralen Großrechner (Mainframe) instal- 
liert. Eine Benutzerinteraktion erfolgte mit Hilfe von Terminals. Vgl. Herden et al. 
(2006), S. 25f. 

323 Vgl. Braunwarth/Heinrich (2008), S. 100. 

324 Vgl. Mas y Parareda/Pizka (2007), S. 60; Sommerville (2001), S. 591. 


325 Vgl. Mas y Parareda/Pizka (2007), S. 60. 
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meisten Fällen von den betreffenden Produktherstellern nicht mehr produziert 
oder unterstützt werden. Dies hat zur Konsequenz, dass Defekte an der Hard- 
ware sich im günstigsten Fall nur über teure Wartungsmaßnahmen beheben oder 
zumindest reduzieren lassen. 

Mit Blick auf den ressourcenintensiven Betrieb einer heterogenen Applikati- 
onslandschaft ist festzustellen, dass die Aufwendungen, die für den Betrieb der 
IT-Landschaft anfallen, insbesondere die so genannte operationelleAgilität der 
Anwendungssysteme gefahrden.326 Die operationale Agilität zielt auf die Fä- 
higkeit einer Unternehmung ab, neue Geschäftspotenziale zu erkennen und die- 
se zeitnah, exakt und kosteneffizient umzusetzen. Betroffen von den Anforde- 
rungen, eine operationale Agilität zu gewährleisten, sind insbesondere die IT- 
Abteilungen, deren Arbeit darauf ausgerichtet ist, in den Unternehmungen eine 
entsprechende Applikationslandschaft mit dem Ziel zu betreiben, die Fach- 
bzw. Anwendungsseite zu untersttitzen.327 

Dadurch, dass zur Überwindung der Heterogenität infolge historisch gewach- 
sener, isolierter und monolithischer Anwendungssysteme beträchtliche Res- 
sourcen seitens der IT-Abteilungen aufgewendet werden müssen, ist das Ziel 
gefährdet, die von der Fach- bzw. Anwendungsseite erwartete IT-Unterstützung 
in einer effizienten und effektiven Weise zu leisten.328 


326 Allgemein lässt sich Agilität als Fähigkeit verstehen, sich an Veränderungen anzupas- 
sen. Vgl. Dorda/Steiert/Sellentin (2004), S. 200. Nach YUSUF/SARHADI/GUNASEKARAN 
lässt sich Agilität (agility) wie folgt definieren: „Agility is the successful exploration of 
competitive bases (speed, flexibility, innovation proactivity, quality and profitability) 
through the integration of reconfigurable resources and best practices in a knowledge- 
rich environment to provide costumer-driven products and services in a fast changing 
market environment“. Yusuf/Sarhadi/Gunasekaran (1999), S. 37. Wie aus dem Definiti- 
onsvorschlag hervorgeht, lässt sich Agilität in die Teilziele Geschwindigkeit, Flexibili- 
tät, proaktive Innovation, Qualität und Profitabilität aufspalten. Die Erfüllung dieser 
Teilziele trägt dazu bei, Produkte und Dienstleistungen anzubieten, die sich an den Be- 
dürfnissen der Kunden orientieren. Vor dem Hintergrund eines wissensintensiven, sich 
schnell ändernden Marktumfelds liegt den Autoren zufolge ein zentraler Erfolgsfaktor 
für diese Zielerreichung in der Integration rekonfigurierbarer Ressourcen. Während der 
Agilitätsbegriff von YUSUF/SARHADI/GUNASEKARAN aus einer allgemeingültigen Sicht 
betrachtet wird, untersuchen SAMBAMURTHY ET AL. die Unterstützungspotenziale, die 
die betrieblichen IS für die Agilität einer Unternehmung bergen. Die Autoren unter- 
scheiden in diesem Zusammenhang die Agilitätstypen operationelle Agilität, kunden- 
sowie partnerorientierte Agilität. Vgl. Sambamurthy et al. (2003), S. 245f. Zur Bedeu- 
tung der kunden- sowie partnerorientierten Agilität vgl. Abschnitt 3.1.3.2. 

327 Vgl. Schelp/Winter (2007), S. 43. 

328 Wie HÖS ET AL. in diesem Zusammenhang bemängeln, lassen sich infolge des erschwer- 
ten Einsatzes integrierter Systeme kein Mehrwert erzielen und keine Redundanzen ver- 


meiden. Vgl. Höß et al. (2007), S. 39. 
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3.1.3.2 Mangelnde IT-Unterstützung von Geschäftsprozessen 


Die im vorherigen Abschnitt thematisierten Problemfelder für die operationelle 
Agilität der IS einer Unternehmung erweisen sich insbesondere als gravierend, 
wenn nicht einzelne isoliert betrachtete Funktionen, sondern funktionsübergrei- 
fende Geschäftsprozesse den Gegenstand einer IT-Unterstützung darstellen.329 
Als verbindendes Glied zwischen der Strategie und der IT einer Unternehmung 
liegt in der Modellierung und Implementierung von Geschäftsprozessen ein 
wichtiger Faktor für den Erfolg einer Unternehmung. Ein Geschäftsprozess 
kann innerhalb einer Organisation und/oder organisationsübergreifend ausges- 
taltet sein, wobei sich die miteinander verknüpften Aktivitäten sequentiell 
und/oder parallel ausführen lassen.330 

Wie sich den Nennungen zu den Treibern einer SOA entnehmen lässt, wird 
gefordert, die Funktionalität der IT stärker an den Geschäftsprozessen einer Un- 
ternehmung auszurichten. Da der Einschätzung von HEß zufolge die Mehrzahl 
der prozessrelevanten Daten in den IT-Systemen vorgehalten wird, ist es erfor- 
derlich, die Daten automatisiert und permanent von den Quellsystemen zu ext- 
rahieren.33! Darüber hinaus lässt sich die Forderung ableiten, mit Hilfe der ext- 
rahierten Daten den gesamten Geschäftsprozess — angefangen bei der Anfrage 
eines Kunden bis zur Auslieferung und zum Zahlungseingang — abzubilden so- 
wie mittels der eingesetzten IT zu automatisieren.332 

Bedenkt man, dass die zu unterstützenden Geschäftsprozesse einem immer 
schnelleren Wandel ausgesetzt sind,333 richtet sich ein weiteres wichtiges Au- 
genmerk auf die Gestaltbarkeit sowie die Anpassungsfähigkeit der Geschäfts- 
prozesse, die sich durch ein hohes Maß an Innovationspotenzial sowie Adapti- 
vität auszeichnen sollen.33* Aus der Zusammenstellung der Nennungen in 
Abbildung 12 geht hervor, dass sowohl die Anpassungsfähigkeit bestehender 
Geschäftsprozesse als auch die Gestaltbarkeit zukünftiger Geschäftsprozesse 
wichtige Treiber für das Interesse an SOA darstellen. SCHELP fügt dieser Fest- 
stellung hinzu, dass der geforderte Änderungs- bzw. Anpassungsbedarf der Ge- 
schäftsprozesse sich nicht nur auf die Leistungsprozesse einer Unternehmung 
beziehen soll, sondern auch auf diejenigen Prozesse und betrieblichen IS ge- 
richtet ist, die der Unterstützung der Leistungsprozesse dienen.335 In diesem Zu- 


329 Vgl. Samtleben/Stadibauer/Hess (2006), S. 87. 

330 Vgl. Hansen/Neumann (2005), S. 233. 

331 Vgl. Heß (2005), S. 19. 

332 Vgl. Heß (2005), S. 19. 

333 Vgl. Lankes et al. (2008), S. 12. 

334 Vgl. Berbner et al. (2005), S. 268. Nach ANDRESEN/GRONAU resultiert der Anpassungs- 
bedarf der Geschäftsprozesse aus den äußeren Einflüssen, die sprunghaft und dynamisch 
auftreten können. Vgl. Andresen/Gronau (2005), S. 30. 


335 Vgl. Schelp (2007), S. 143f. 
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sammenhang konstatieren MODJO KAMNENG ET AL., dass insbesondere die ge- 
ringe IT-Unterstützung von Geschäftsprozessen, deren Abläufe nicht im Vor- 
feld festgelegt sind, ein aktuelles Problemfeld darstellt.336 

Eine weitere wichtige Triebfeder, die sich aus den Nennungen zu den SOA- 
Treibern schlussfolgern lässt, liegt in der Forderung nach einer ganzheitlichen 
bzw. durchgängigen Unterstützung der Geschäftsprozesse über Systemgrenzen 
hinweg mit dem Ziel,337 auf diese Weise die Wettbewerbsfähigkeit von Unter- 
nehmungen sicher zu stellen.?38 Betroffen sind hiervon nicht nur die unterneh- 
mungsinternen, sondern auch die -übergreifenden Prozesse.33? Dies impliziert 
wiederum, dass nicht nur die unternehmungsinternen, sondern auch die - 
externen Anwendungssysteme für eine ganzheitliche Prozessunterstützung zu 
integrieren sind. Eine Verknüpfung der heterogenen und monolithischen An- 
wendungssysteme auf der Prozessebene stellt eine wichtige Anforderung dar, 
damit eine Automatisierung der Geschäftsprozesse, die auf die jeweiligen Sys- 
teme aufsetzen, erfolgen kann.34° 

Gefordert wird in diesem Zusammenhang der Betrieb einer flexiblen IT- 
Architektur, um die Vielzahl der heterogenen Altanwendungen, Plattformen, 
Betriebssysteme und Kommunikationsmechanismen zu integrieren und eine hö- 
here Adaptierbarkeit der Geschäftsprozesse zu erreichen.34! Eine IT-Architektur 
umfasst neben der IS-Architektur die Vorgehensmodelle, die zur Gestaltung der 
IS zum Einsatz kommen.342 Zu unterscheiden ist eine IT-Architektur von einer 
Geschäftsarchitektur, die die Definition und Strukturierung der Geschäftspro- 
zesse, Geschäftsobjekte und Organisationsstrukturen fokussiert.343 Nach diesem 
Verständnis setzen sich die Geschäfts- und die Systemarchitektur zur Unter- 
nehmungsarchitektur zusammen.344 

Mit Blick auf die eingangs beschriebenen vertikal organisierten IT- 
Strukturen einer Unternehmung ist festzustellen, dass einer Unterstützung von 
Geschäftsprozessen über Systemgrenzen hinweg durch den Einsatz monolithi- 


336 Vgl. Modjo Kamneng et al. (2007), S. 289. 

337 Vgl. Heß (2005), S. 19. 

338 Vgl. Grimm (2005), S. 17. Nach GLOCKLE liegt hierin das Ziel der IT-Integration. Um 
dieses Ziel zu erreichen, sind dem Autor zufolge eine Infrastruktur sowie die notwendi- 
gen Ressourcen bereitzustellen. Vgl. Glöckle (2007), S. 8. 

339 Vgl. Grimm (2005), S. 17. 

340 Vgl. Kossmann/Leymann (2004), S. 117. 

341 Vgl. Keller (2002), S. 25. 

342 Vgl. Ackermann et al. (2006), S. 184. 

343 Vgl. Foegen/Battenfeld (2001), S. 293. Eine alternative Sichtweise, die keine begriffli- 
che Trennung zwischen einer Geschäftsarchitektur und einer IT-Architektur vorsieht, 
vertreten MÜLLER ET AL. Nach der Auffassung der Autoren setzt sich eine IT- 
Architektur aus der verwendeten Hard- und Software, den Geschäftsprozessen und der 
Organisationsstruktur einer Unternehmung zusammen. Vgl. Müller et al. (2006), S. 187. 


344 Vgl. Foegen/Battenfeld (2001), S. 293f. 
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scher und heterogener Anwendungssysteme augenblicklich 1. d. R. enge Gren- 
zen gesetzt sind. Daraus ergibt sich die Gefahrenquelle, dass die so genannte 
kunden- sowie partnerorientierte Agilität nicht mehr gewährleistet werden kann. 
Unter kundenorientierter sowie partnerorientierter Agilität lässt sich die Fähig- 
keit einer Unternehmung auffassen, von seinen Kunden sowie Geschäftspart- 
nern zu lernen und auf Basis der neu erworbenen Fähigkeiten und Kompetenzen 
neue Geschäftspotenziale zu identifizieren, die es in einem nächsten Schritt ge- 
meinsam mit den Partnern umzusetzen gilt. Im Fokus der kunden- und partner- 
orientierten Agilität liegen die Geschäftsprozesse, die im ersten Fall beispiels- 
weise durch den Einsatz von Kundenportalen, im zweiten Fall durch die Gestal- 
tung einer unternehmungsübergreifenden Logistikkette z. B. unter Verwendung 
eines Supply Chain Management-Tools durch die betriebliche IT unterstützt 
werden kénnen.345 

Nachdem in den bisherigen Ausführungen, ausgehend von einer Zustands- 
beschreibung der betrieblichen IS, die wesentlichen Treiber vorgestellt wurden, 
die zu einem wachsenden Interesse an SOA beigetragen haben, widmen sich die 
folgenden Ausführungen den Eigenschaften sowie den Potenzialen, die im Zu- 
sammenhang mit diesem derzeit viel beachteten Ansatz diskutiert werden. 


3.2 Sichtweisen auf SOA 


Der schillernde Begriff „SOA“ hat insbesondere seit 2005 eine Reihe von Vor- 
schlägen hervorgebracht, die sich mit den Fragen beschäftigen, was unter einer 
SOA zu verstehen ist und welchen Beitrag SOA für die Unterstützung einer in- 
tegrierten Informationsverarbeitung leisten kann.346 Eine z. T. euphorische Er- 
wartungshaltung hinsichtlich der Bedeutung von SOA wird nicht nur von vielen 
Beratungs-, Marktforschungs- und Softwareunternehmungen vertreten, die in 
SOA einen Megatrend sehen.34’ Die positive Einschätzung von SOA kommt 
auch in vielen wissenschaftlichen Beitragen zum Ausdruck.348 Der Aussage von 


345 Vgl. Schelp/Winter (2007), S. 43. 

346 Die Aktualität des Einsatzes einer SOA lässt sich u. a. durch eine Studie belegen, die im 
Jahr 2007 von AMADEE/MARTIN durchgeführt wurde. Während 85 % der in dieser Stu- 
die befragten Unternehmungen SOA eine Bedeutung einräumen, spielt dieses Thema für 
50 % der Unternehmungen eine große oder sehr große Rolle. Vgl. Amadee/Martin 
(2007), S. 6. 

347 Vgl. Buxmann/Hess/Widjaja (2007), S. 1316. Gleichzeitig weisen KACZMAREK/WECEL 
darauf hin, dass der SOA-Begriff gerade von diesen Unternehmungen übermäßig und in 
einem falschen Verständnis gebraucht wurde. Vgl. Kaczmarek/Wecel (2008), S. 52. 

348 HOLTSCHKE/HEIER/HUMMEL bemerken in diesem Zusammenhang, dass die mediale 
Aufmerksamkeit des SOA-Begriffs derzeit einen für Innovationen typischen Verlauf 
nimmt, bei diesem nach anfänglichen Übertreibungen und Fehleinschätzungen eine Pha- 


se der Ernüchterung zu erwarten ist. Vgl. Holtschke/Heier/Hummel (2009), S. 120. 
Alexander Pastwa - 978-3-631-75488-7 


Downloaded from PubFactory at 01/11/2019 04:20:29AM 
via free access 


Serviceoricntierte Architekturen (SOA) als innovatives Konzept für eine integrierte Informationsverarbeitung 71 


CONRAD ET AL. zufolge handelt es sich bei einer SOA um die Ausprägung einer 
prozessorientierten Architektur, die aktuell am meisten diskutiert wird.349 Nach 
der Auffassung von DUECK steht SOA für das Hype-Kürzel des Jahres 2006.350 
Während nach der Einschätzung von LAARTZ die betriebswirtschaftlichen Aus- 
wirkungen einer SOA als revolutionär einzustufen sind,35! favorisieren KARCH 
ET AL. die Bezeichnung “sanfte Revolution“ zur Einordnung der Potenziale ei- 
ner SOA.352 

Die zu erwartenden Auswirkungen von SOA auf die integrierte Informati- 
onsverarbeitung werden ebenfalls in der Aussage von HANSEN/NEUMANN deut- 
lich, die davon sprechen, dass SOA das kommende Jahrzehnt von Integrations- 
lösungen beherrschen wird.353 Für VOM BROCKE steht SOA gar für eine neue 
Generation von Anwendungssystemen.354 Zu einem positiven Urteil kommt 
auch KRUCZYNSKI, für den kein Zweifel besteht, dass SOA die Informations- 
technologie hin zu mehr Flexibilität und Performancegewinn begünstigen 
wird.355 MELZER ET AL. räumen SOA gar das Potenzial ein, sich nach der ob- 
jektorientierten Programmierung als das nächste Paradigma in der Informatik zu 
etablieren.356 Damit repräsentiert die letztgenannte Einschätzung, bei SOA han- 
dele es sich um ein neues Paradigma bzw. einen Paradigmenwechsel, den au- 
genblicklich populärsten Versuch, die Potenziale bzw. Auswirkungen von SOA 
auf wenige Schlagworte zu reduzieren.357 

Bisher ist es keinem Beitrag gelungen, ein Begriffsverständnis oder ein klar 
umrissenes Begriffsgebäude zu SOA zu präsentieren, das zu einer autorenüber- 
greifenden Zustimmung geführt hat.358 Einerseits sind die in der Literatur prä- 


349 Vgl. Conrad et al. (2006), S. 88. 

350 Vgl. Dueck (2006), S. 366. 

35l Vgl. Laartz (2008), S. 72. 

352 Vgl. Karch et al. (2004), S. 209. 

353 Vgl. Hansen/Neumann (2005), S. 532. 

354 Vgl. vom Brocke (2007), S. 84. 

355 Vgl. Kruczynski (2006), S. 24. 

356 Vgl. Melzer et al. (2007), S. vii. 

357 Vertreter dieser Sichtweise sind beispielsweise HOB ET AL., HOFMANN, KÜSTER, SIE- 
BENHAAR ET AL. und SCHRÖPFER/SCHÖNHERR. Vgl. Höß et al. (2007), S. 39, 40 und 45; 
Hofmann (2003), S.27; Küster (2003), S.5; Siebenhaar et al. (2008), S. 325; 
Schröpfer/Schönherr (2008), S. 409. 

358 Vgl. Buxmann/Hess/Widjaja (2007), S. 1316; Höß et al. (2007), S. 40; Liebhart (2007), 
S. 6. KACZMAREK/WECEL bemerken in diesem Zusammenhang die Existenz hunderter 
Definitionen zum SOA-Konzept. Vgl. Kaczmarek/Wecel (2008), S. 52. Die Feststel- 
lung, dass das derzeit vorherrschende Begriffsverständnis zu SOA durch Heterogenität 
gekennzeichnet ist, wird ferner durch die Initiative der Bundesregierung untermauert, 
die im Rahmen der CEBIT 2007 gemeinsam mit dem Branchenverband BITKOM An- 
forderungen an eine SOA-Taskforce formuliert hat, deren Aufgabenbereich u. a. die De- 


finitio dlegender Begriffe umfasst. Vgl. B n/Hess/Widjaja (2007), S. 1316. 
nition grundlegender Begriffe umfasst Ygl, Buzemann less Eli (P07; 
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sentierten Definitionsansätze von Überschneidungen, andererseits von Unter- 
schieden gekennzeichnet.359 Auch im Hinblick auf die Vielfalt der in den Bei- 
trägen diskutierten Merkmale einer SOA ist zu konstatieren, dass sowohl allge- 
meine als auch sehr fokussierte Definitionsvorschläge zu einem uneinheitlichen 
Verständnis beigetragen haben.360 Während in einigen Beiträgen technische 
Aspekte im Vordergrund stehen, favorisieren andere die fachlichen bzw. be- 
triebswirtschaftlichen Nutzungspotenziale einer SOA.36! Zudem zeichnen sich 
die Beiträge in erschwerender Weise durch eine unterschiedliche Gewichtung 
der in den jeweiligen Ansätzen thematisierten Eigenschaften einer SOA aus.362 
Auch wenn die aktuell existierenden SOA-Auslegungen keine scharfe Begriffs- 
erklärung liefern,363 lassen sich dennoch einige Merkmale einer SOA anführen, 
die zumindest von einer Mehrheit der Autorenschaft thematisiert werden und 
daher als SOA-konstituierende Eigenschaften bezeichnet werden können. 

Um die Spannweite der verschiedenen SOA-Begriffsdefinitionen zu verdeut- 
lichen und darauf aufbauend in Abschnitt 3.5 ein integriertes Begriffsverständ- 
nis zu präsentieren, werden zunächst exemplarisch einige Definitionen vorge- 
stellt. Aus den Literaturvorschlägen zur Bestimmung des SOA-Begriffs lassen 
sich drei Strömungen identifizieren, die in den folgenden Abschnitten konkreti- 
siert werden. Ausgehend von einem konzeptionell geprägten Begriffs- 
verständnis, das in Abschnitt 3.2.1 präsentiert wird, widmet sich Abschnitt 3.2.2 
einer Perspektive, in der die technische Implementierung einer SOA im Vorder- 
grund steht. Alternativ zu den beiden vorangehenden Sichtweisen fokussiert 
Abschnitt 3.2.3 ein Begriffsverständnis, das die gestalterischen Aspekte einer 
SOA betont. 


3.2.1 SOA als Informationssystem-Architektur 


Der ersten Auslegung des SOA-Begriffs liegt die Vorstellung zugrunde, dass 
sich SOA als Informationssystem-Architektur (IS-Architektur) auffassen 
lässt.36* Als Vertreter dieser Sichtweise wird der Definitionsansatz von MELZER 
ET AL. vorgestellt. Die Autoren bemerken, dass es sich bei einer SOA um eine 
Systemarchitektur handelt, „die vielfältige, verschiedene und eventuell inkom- 
patible Methoden oder Applikationen als wiederverwendbare und offen zu- 


359 Vgl. Melzer et al. (2007), S. 11. 

360 Vgl. hierzu auch Melzer et al. (2007), S. 11. Auf die unterschiedliche Schwerpunkt- 
setzung im Themenfeld SOA verweisen auch de Hesselle/Klüpfel/Bauersachs (2008), 
S. 30. 

361 Vgl. Buxmann/Hess/Widjaja (2007), S. 1316; Kaczmarek/Wecel (2008), S. 52; 
Schröpfer/Schönherr (2008), S. 409. 

362 Vgl. hierzu auch Richter/Haller/Schrey (2005), S. 413. 

363 Vgl. de Hesselle/Klüpfel/Bauersachs (2008), S. 30. 


364 Zu dieser Überzeugung kommt auch Coldewey (2007), S. 50. 
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greifbare Dienste repräsentiert und dadurch eine plattform- und sprachunabhän- 
gige Nutzung und Wiederverwendung ermöglicht“.365 Wie aus diesem Definiti- 
onsvorschlag hervorgeht, sind sowohl der Architekturgedanke als auch die Ser- 
viceorientierung zentrale Charakteristika einer SOA. Mit Blick auf den Aspekt 
der Serviceorientierung liegt der Leitgedanke einer SOA darin, Methoden, die 
eine fachliche Logik repräsentieren, softwaretechnisch in Form von Diensten 
bzw. Services abzubilden und für eine mehrfache Nutzung zur Verfügung zu 
stellen.366 Eine hohe Wiederverwendbarkeit hat zur Folge, dass sich die imple- 
mentierten Services für viele Problemstellungen bzw. in einer Vielzahl von 
Anwendungen nutzen lassen.36’ Die Dienste lassen sich dabei aus den Realisie- 
rungen der diversen betrieblichen Anwendungen gewinnen.36 Als technisches 
sowie konzeptionelles Fundament dient eine spezielle IS-Architektur, die die 
Autoren als SOA bezeichnen.369 

Mit ihrer SOA-Auslegung folgen MELZER ET AL. der gebräuchlichen Praxis, 
den Architekturbegriff für Konzepte der Informationsverarbeitung zu verwen- 
den.370 Ein Zugang zum Architekturbegriff lässt sich über ein allgemeines Beg- 
riffsverständnis erzielen.37! Dieses besagt, dass eine Architektur die Struktur ei- 
nes Systems definiert,372 die sich ganzheitlich sowie auf einer abstrakten Ebene 
betrachten lässt.373 Eine Architektur beschreibt sowohl die logische und physi- 
kalische Anordnung der Bausteine eines komplexen Systems als auch ihre Be- 
ziehungen zueinander,374 wobei im Mittelpunkt die Darstellung der funktionel- 
len Zusammenhänge eines Systems steht.375 Darüber hinaus sind innerhalb einer 
Architektur Richtlinien vorgegeben, die dazu dienen, die Systemkomponenten 
sowie ihre Beziehungen zueinander zu gestalten und weiterzuentwickeln.376 

Eine IS-Architektur steht für die Idee, eine strukturelle Sichtweise mit einer 
modellorientierten Perspektive zu verbinden.?7’ Da die Beschreibung auf einer 
grobgranularen Ebene stattfindet, steht das Grobdesign des IS im Mittel- 


365 Melzer et al. (2007), S. 11. 

366 FIEGE/STELZER zufolge ist gerade die Wiederverwendbarkeit der Services eines der 
wichtigsten Architekturziele einer SOA. Vgl. Fiege/Stelzer (2007), S. 911. 

367 Vgl. Winkler (2007), S. 258. 

368 Vgl. Gimnich (2007), S. 68. 

369 Als alternative Bezeichnung lässt sich auch der Begriff Systemarchitektur verwenden. 

370 Vgl. Strunz (1990), S. 441. 

371 HERDEN ET AL. weisen in diesem Zusammenhang darauf hin, dass sich bisher kein ein- 
heitliches Verständnis zum Architekturbegriff durchgesetzt hat. Vgl. Herden et al. 
(2006), S. 1. 

372 Vgl. Petersohn (2004), S. 16. 

373 Vgl. Aier/Schönherr (2006), S. 188. 

374 Vgl. Hansen/Neumann (2005), S. 174; Bleek/Wolf (2008), S. 84. 

375 Vgl. Petersohn (2005), S. 21. 

376 Vgl. Heutschi/Legner/Osterle (2006), S. 362. 


377 Vgl. Kremar (2003), S. 39. 
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punkt.378 Neben der softwaretechnischen Architektur ist die Definition einer 
Infrastrukturarchitektur als weiterer Teilbereich einer Systemarchitektur von 
Bedeutung.379 Charakteristisch für eine softwaretechnische Architektur bzw. 
Softwarearchitektur ist, dass ihre Softwarekomponenten, ihre Schnittstellen und 
ihre Beziehungen beschrieben werden.380 Die Komponenten lassen sich dabei 
auf unterschiedlichen Abstraktionsebenen betrachten, wobei jede Abstraktions- 
ebene die darunter liegenden Details verbirgt.38! Im Vergleich zur software- 
technischen Architektur zeichnet sich die Infrastrukturarchitektur durch eine 
ganzheitliche, operationale Perspektive auf das zu gestaltende System aus. Der 
Fokus bei der Infrastrukturarchitektur richtet sich zum einen auf das technische 
System, d. h. auf die Hardware, Plattformen und deren Verbindungen, zum an- 
deren auf die Platzierung der Softwarekomponenten innerhalb des Systems. 
Darüber hinaus stehen bei der Infrastrukturarchitektur die Konfiguration und 
das Management des Systems im Mittelpunkt.382 

Einen ergänzenden Aspekt zur Sichtweise von MELZER ET AL. fügen 
HEUTSCHV/LEGNER/ÖSTERLE an, nach deren Auffassung es sich bei einer SOA 
um eine „mehrschichtige, verteilte Informationssystem-Architektur (IS)- 
Architektur handelt, die Teile der Applikationsarchitektur als Services kapselt 
und dabei eine Reihe von Designprinzipien berücksichtigt“.?3 In Analogie zum 
Definitionsansatz von MELZER ET AL. betonen die Autoren die Bedeutung von 
Diensten, die auf der fachlichen Logik der Anwendungssysteme basieren und 
nach bestimmten Vorgaben in Form von Designprinzipien zu entwickeln und zu 
nutzen sind. Eine Applikationsarchitektur richtet sich auf die Beschreibung der 
statischen und dynamischen Strukturen von Anwendungssystemen.384 Mit Blick 
auf den Architekturaspekt einer SOA verweisen HEUTSCHI/LEGNER/OSTERLE in 
Erweiterung des Begriffsverständnisses von MELZER ET AL. darauf, dass es sich 
bei einer SOA nicht um ein zentralisiertes, monolithisches Konstrukt, sondern 
um eine verteilte IS-Systemarchitektur handelt. 

Die Eigenschaft einer verteilten Architektur bedeutet, dass sich die Hard- 
ware- und Softwarekomponenten, die im Rahmen einer SOA zum Einsatz 
kommen, auf vernetzten Computerressourcen befinden, wobei eine Kommuni- 
kation zwischen diesen Komponenten über den Austausch von Nachrichten er- 
folgt.385 Der Aspekt der Verteilung bezieht sich in diesem Zusammenhang auf 


378 Vgl. Hansen/Neumann (2005), S. 223. 

379 Vgl. Foegen/Battenfeld (2001), S. 294ff. 

380 Vgl. Fink/Schneidereit/Voß (2005), S. 211. 

381 Vgl. Foegen/Battenfeld (2001), S. 296. 

382 Beim letzten Aspekt sind beispielsweise die Kapazitätsplanung, die Datensicherung und 
der Wiederanlauf von Bedeutung. Vgl. Foegen/Battenfeld (2001), S. 294. 

383 Heutschi/Legner/Osterle (2006), S. 362. 

384 Vel. Müller (2007), S. 143. 


385 Siehe hierzu die Definition eines verteilten Systems bei Hammerschall (2005), S. 16f. 
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die Möglichkeit, in einer SOA bestehende Applikationen durch die Vernetzung 
autonomer und plattformunabhängiger Dienste zu kollaborativen Anwendungen 
weiter zu entwickeln.386 

Die bisherigen Definitionsansätze werden von RICHTER/HALLER/SCHREY und 
HESS/HUMM/VOß um einen weiteren Aspekt ergänzt. Den Autoren zufolge han- 
delt es sich bei einer SOA um „ein Architekturmuster, das den Aufbau einer 
Anwendungslandschaft aus einzelnen fachlichen Anwendungsbausteinen be- 
schreibt, die jeweils eine klar umrissene Aufgabe wahrnehmen. Die Anwen- 
dungsbausteine sind lose miteinander gekoppelt, indem sie einander ihre Funk- 
tionalitäten in Form von Services anbieten“.387 Mit Blick auf den Architektur- 
musterbegriff wird in der Definition von RICHTER/HALLER/SCHREY deutlich, 
dass SOA als Referenzarchitektur verstanden wird, die für die Implementierung 
sowie Nutzung verschiedener Anwendungsbausteine in Form von Services zum 
Einsatz kommen kann.388 

Ganz besonders ist es den Autoren wichtig, auf das Prinzip der losen Kopp- 
lung hinzuweisen. Dieses liefert zum einen die Voraussetzung für die Inan- 
spruchnahme der Funktionalitäten der Dienste, die für einen bestimmten 
Einsatzzweck konzipiert und implementiert werden.389 Zum anderen soll die 
Einhaltung dieses Prinzips bewirken, dass die Schwachstellen, die sich infolge 
des Einsatzes monolithischer Systeme ergeben,3%0 durch die einfache Kopplung 
und Entkopplung einzelner Funktionen sowie kompletter Anwendungssysteme 
auf Basis entsprechender Services beseitigt werden.3?! 


3.2.2 SOA als konkrete technische Implementierung eines Softwaresystems 
auf Basis von Web Services 


Während in den bisherigen Definitionsansätzen SOA auf einer abstrakten Ebene 
betrachtet wurde, fokussiert der Vorschlag von LAUDON/LAUDON/SCHODER die 
konkrete, technische Implementierung einer SOA. Ihre Definition lautet: „A 
collection of Web services that are used to build a firm’s software systems con- 
stitutes what is known as a service-oriented architecture. A service-oriented ar- 
chitecture (SOA) is a set of self-contained services that communicate with each 


386 Vgl. Eymann/Winter (2008), S. 70. 

387 Richter/Haller/Schrey (2005), S. 413. 

388 Vor diesem Hintergrund greift die Definition von FOEGEN/BATTENFELD, die ein Archi- 
tekturmuster mit einer Referenzarchitektur gleichsetzen, die sowohl funktionale als auch 
operationale Aspekte für eine bestimmte Klasse von Anwendungen beschreibt. Vgl. 
Foegen/Battenfeld (2001), S. 298. 

389 Vgl. hierzu Abschnitt 3.3.2.2. 

390 Vgl. Abschnitt 3.1.2. 

391 Siehe hierzu Abschnitt 3.1.3.1, der die Kosten des IT-Betriebs als Treiber für das Inte- 


resse an SOA thematisiert. 
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other to create a working software application.”392 Weitere Vertreter für die 
technikorientierte Sichtweise sind TERZIDIS/SURE/BRELAGE. Ihre Definition hat 
folgenden Wortlaut: „SOA modularizes monolithic software packages into 
manageable application components which are offered as standardized Web 
Services in an expandable repository“.393 

Im Unterschied zu den bereits präsentierten Begriffsverständnissen wird in 
diesen beiden Definitionsvorschlägen deutlich, dass für die Autoren die Reali- 
sierung einer SOA gleichbedeutend mit dem Einsatz von Web Services ist.3%4 
Folglich lässt sich dieser Definitionsvorschlag als ein sehr enges, technikorien- 
tiertes Begriffsverständnis einer SOA werten. 


3.2.3 SOA als Konzept zur Gestaltung prozessorientierter Anwendungen 


Neben dem konzeptionell geprägten sowie technikorientierten Begriffsver- 
ständnis betont eine andere Sichtweise das gestalterische Potenzial, das der 
SOA-Ansatz bietet. Einen entsprechenden Definitionsansatz liefert die Markt- 
forschungsunternehmung FORRESTER RESEARCH. Diesem Vorschlag zufolge 
handelt es sich bei einer SOA um die „Art und Weise, wie Anwendungen und 
SW-Architekturen gestaltet, bereitgestellt und verwaltet werden“.395 In dieser 
Definition wird die bisher statische Perspektive auf eine SOA um eine dynami- 
sche Sichtweise ergänzt. In Abgrenzung zu den vorangehenden Definitionen 
steht nach der Vorstellung von FORRESTER RESEARCH der Begriff einer SOA für 
einen bestimmten Stil, wie Anwendungen und SW-Architekturen entwickelt 
und betrieben werden können. 

Den Fokus auf den Gestaltungsaspekt einer SOA legen auch LOMOW/ 
NEWCOMER. Ihr Definitionsansatz lautet: „A service-oriented architecture is a 
style of design that guides all aspects of creating and using business services 
throughout their lifecycle (from conception to retirement). An SOA is also a 
way to define and provision an IT infrastructure to allow different applications 
to exchange data and participate in business processes, regardless of the operat- 
ing systems or programming languages underlying those applications.”396 Ein 
wichtiger Akzent in dieser Definition richtet sich auf den Prozess zur Entwick- 
lung der Dienste sowie den gesamten Lebenszyklus der im Rahmen einer SOA 
zu nutzenden Services. Nach NEWCOMER/LOMOW steht der Ansatz einer SOA 


392 Taudon/Laudon/Schoder (2006), S. 214. 

393 Terzidis/Sure/Brelage (2008), S. 76. 

394 Neben Laudon/Laudon/Schoder und Terzidis/Sure/Brelage gelten als weitere Vertreter 
dieser Sichtweise beispielsweise ERL, LIEBHART, RIEKS und STREIBICH. Vgl. Erl (2005), 
S. 54; Liebhart (2007), S.5 und 11; Rieks (2006), S. 7; Streibich (2008), S. 73. Zur 
Technologie der Web Services vgl. Abschnitt 3.4. 

395 Liebhart (2007), S. 6. 


396 Newcomer/Lomow (2005), S. 13. 
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für einen Entwurfsstil, der sowohl der Entwicklung als auch der Nutzung der 
Services zugrunde liegt. Gleichzeitig verstehen die Autoren SOA als Gestal- 
tungsprozess zur Entwicklung und zum Betrieb einer IT-Infrastruktur, die dazu 
dient, losgelöst von der softwaretechnischen Ausprägung der zum Einsatz 
kommenden Anwendungssysteme, eine Unterstützung der Geschäftsprozesse zu 
realisieren. 


Aktivität 2 Aktivität 4 


Aktivität 1 


‚Anwendung 1 ! 


Abbildung 14: Zusammenhang zwischen Prozessaktivitäten, Services und Anwendungs- 
systemen 


HESS/HuMM/VOß ergänzen, dass der Aufruf von Services über einen einheitli- 
chen Mechanismus es erlaubt, „Geschäftsprozesse auf der Basis von Services 
möglichst einfach zu implementieren und zu 4ndern“.397 Das Anwendungsfeld 
der in einer SOA eingebundenen Dienste richtet sich dabei nach der Auffassung 
von HESS/HUMM/Vo8 auf die Unterstützung von Geschäftsprozessen, die durch 
die Verknüpfung voneinander unabhängiger Services, an Flexibilität gewinnen 
können. Diese Aussage wird durch Abbildung 14 gestützt. Wie in dieser Abbil- 
dung zu erkennen ist, werden die Dienste, die innerhalb einer Anwendung eine 
Aufgabe erfüllen, zu einer Prozesskette verknüpft und als Prozessaktivitäten 


397 Vgl. Hess/Humm/VoB (2006), S. 396. 
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ausgeführt. Das Zusammenfügen von Services wird auch als Komposition be- 
zeichnet. 

Im Ergebnis verdeutlicht die Definition von HESS/HUMM/Vos, dass SOA 
nicht nur einen rein technischen Bezug, sondern auch einen fachlichen An- 
spruch hat, der sich sowohl auf die Automatisierung als auch auf die Flexibili- 
sierung von Geschäftsprozessen richtet. 


3.3 Services als Basiselemente einer SOA 


Losgelöst von ihren unterschiedlichen Ausrichtungen, zeichnen sich die in Ab- 
schnitt 3.2 präsentierten Auslegungen einer SOA durch die Gemeinsamkeit aus, 
dass die Softwareservices das zentrale Charakteristikum einer SOA darstel- 
len.398 Die bisherigen, in der SOA-Literatur erarbeiteten Vorschläge zur Defini- 
tion des Servicebegriffs haben zu einem Erkenntnisstand geführt, bei dem ver- 
schiedene Sichtweisen miteinander konkurrieren. In diesem Zusammenhang ist 
zu konstatieren, dass es sich bei den verschiedenen Ansätzen zur Beschreibung 
und Abgrenzung eines Services bzw. eines Dienstes nicht um disjunkte Defini- 
tionsvorschläge handelt.399 Vielmehr beschränken sich die Autoren in ihren 
Beiträgen auf die Darstellung verschiedener, z. T. sich ergänzender Aspekte, die 
nicht im Gegensatz zu den Inhalten anderer Bestimmungsversuche stehen. 

Das Ziel der folgenden Ausführungen liegt darin, die in den verschiedenen 
Literaturbeiträgen präsentierten Eigenschaften und Gestaltungsprinzipien von 
Services zu einem vollständigen Begriffsverständnis zusammenzuführen. Mit 
Blick auf ihre Bedeutung als fundamentale Bausteine einer SOA widmen sich 
die Ausführungen des Abschnitts 3.3.1 der Frage, welche charakteristischen Ei- 
genschaften Services aufweisen, die innerhalb einer SOA genutzt werden.400 
Nach den Grundlagen zu den Bestandteilen eines Services werden in Abschnitt 
3.3.2 zentrale Gestaltungsprinzipien vorgestellt, die bei der Entwicklung sowie 
dem Einsatz von Services zu berücksichtigen sind. 


398 Dass Services das zentrale Designobjekt einer SOA darstellen, wird auch bei HANHART/ 
LEGNER/ÖSTERLE deutlich. Vgl. Hanhart/Legner/Österle (2008), S. 478. 

399 Zur Vermeidung einer sprachlichen Monotonie werden die Begriffe „Services“ und 
„Dienste“ im Folgenden synonym verwendet. 

400 Zur Bedeutung der Services im Rahmen einer SOA vgl. Newcomer/Lomow (2005), 
S. 55. Dass Services das wichtigste Element einer SOA repräsentieren, wird auch bei 


LIEBHART deutlich. Vgl. Liebhart zu! S. ae Bac} ee er re 
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3.3.1 Begriff des Services 


Aus einer softwaretechnischen Perspektive betrachtet,#0! lassen sich Services 
als Softwarekomponenten verstehen, die eine abgegrenzte und standardisierte 
Funktionalität anbieten, die wiederum Bestandteil eines größeren Verarbei- 
tungsablaufs ist.402 Services werden über eine Schnittstelle lokal oder über ein 
Netzwerk aufgerufen. Dieser Vorstellung folgend, weisen Dienste den Charak- 
ter von abgegrenzten Softwaremodulen auf, die als Programmbausteine sowohl 
in Form von Prozeduren als auch Funktionen softwaretechnisch implementiert 
werden können.#03 Die Bestandteile eines Services sowie die zwischen diesen 
existierenden Beziehungen lassen sich anhand eines Servicemodells verdeutli- 
chen, das in Abbildung 15 dargestellt ist. 


beschreibt 
Software- Service- 


komponente spezifikation 


Funktion(en) 


besitzt 


beschreibt 


Service- 


Nachricht schnittstelle 


definiert 


Abbildung 15: Servicemodell 


Ein Service stellt eine Softwarekomponente dar, die einen Namen besitzt und 
über diesen Namen aufgerufen werden kann. Darüber hinaus verfügen Dienste 
über eine Schnittstelle, die den Zugriffspunkt auf die von dem jeweiligen Servi- 
ce bereitgestellte Funktionalität darstellt.*%% Die Funktionalität steht für eine 
klar umrissene Aufgabe, die der Service erbringen soll. Zur Bereitstellung der 
Funktionalität werden ein oder mehrere Serviceoperationen ausgeführt, die in 
der Serviceschnittstelle definiert werden. 


401 EYMANN/WINTER verdeutlichen, inwieweit sich der softwaretechnisch geprägte Service- 
begriff, der einer SOA zugrunde liegt, aus dem Serviceverständnis ableiten lässt, das in 
der Wirtschaftswissenschaft vorherrscht. Vgl. Eymann/W inter (2008), S. 70. Zum be- 
triebswirtschaftlich orientierten Servicebegriff vgl. Buhl et al. (2008), S. 61f. 

402 Vgl. Humm/Juwig (2006), S. 2. 

403 Vgl. Richter/Haller/Schrey (2005), S. 413. 


404 Vgl. Liebhart (2007), S. 9; Samtleben/Stadlbauer/Hess (2006), S. 91. 
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Der Aufruf von Diensten bzw. die Kommunikation von Diensten untereinan- 
der erfolgt über den Austausch von Nachrichten. In diesem Zusammenhang be- 
sitzt die Serviceschnittstelle die Aufgabe, die für die Inanspruchnahme eines 
Dienstes notwendigen Eingabe- und Ausgabeparameter sowie die Struktur der 
Nachricht festzulegen.4°5 Als weiterer Bestandteil eines Dienstes ist die Servi- 
cespezifikation, die auch als Servicebeschreibung oder Servicevertrag bezeich- 
net wird, zu nennen. Die Servicebeschreibung führt alle Informationen zur Ser- 
vicenutzung auf, die über die Schnittstellenbeschreibung hinausgehen. Während 
die Servicespezifikation einen Dienst beschreibt, handelt es sich bei der Servi- 
ceschnittstelle um die softwaretechnische Realisierung einer Servicespezifika- 
tion.406 


3.3.2 Prinzipien zum Design von Services 


Ausgehend von dem im vorherigen Abschnitt präsentierten, einer SOA zugrun- 
de liegenden Verständnis zum Dienstbegriff, widmen sich die Ausführungen 
dieses Abschnitts der Frage, welche grundsätzlichen Empfehlungen für den 
Entwurf einer SOA zu berücksichtigen sind.407 Hierzu wurde in den relevanten 
Beiträgen der vergangenen Jahre eine Reihe von Prinzipien vorgeschlagen, die 
sich vor diesem Hintergrund auch als Designprinzipien bezeichnen lassen.48 In 
Analogie zum Ansatz der Objektorientierung, in dessen Rahmen beispielsweise 
die Prinzipien des Information Hiding (Geheimnisprinzip), der Vererbung, des 
Polymorphismus, usw. charakteristische Konzepte bilden, lassen sich auch im 
Zusammenhang mit dem Ansatz der Serviceorientierung allgemeingültige Prin- 
zipien ableiten.409 

Eine von HEUTSCHI/LEGNER/OSTERLE durchgeführte Auswertung ausge- 
wählter Beiträge hat ergeben, dass sich bisher kein Konsens herauskristallisiert 


405 Vgl. Heutschi/Legner/Osterle (2006), S. 363f. 

406 Vgl. Heutschi (2007), S. 191. 

407 Mit Blick auf die Bedeutung des Prinzipbegriffs folgt die vorliegende Arbeit dem Ver- 
ständnis von BALZERT, nach dessen Auffassung es sich bei Prinzipien um Grundsätze 
handelt, die sich durch einen allgemeingültigen sowie abstrakten Charakter auszeichnen 
und sich sowohl aus der Erfahrung und Erkenntnis herleiten als auch durch diese bestä- 
tigen oder widerlegen lassen. Vgl. Balzert (2001), S. 36. 

408 ERL zufolge ist die Einhaltung der Prinzipien erforderlich, um die Architekturziele einer 
SOA zu erfüllen. Vgl. Erl (2005), S. 290. Da die von ERL thematisierten Designprinzi- 
pien sich allesamt auf den Entwurf von Services beziehen, wird im Folgenden die Auf- 
fassung vertreten, dass es sich hierbei um Designprinzipien handelt. 

409 Eine Vertiefung der objektorientierten Konzepte liefert beispielsweise BALZERT. Vgl. 
Balzert (2001), S. 152ff. Zur Vermeidung einer sprachlichen Monotonie werden im Fol- 
genden die Begriffe Prinzipien und Konzepte synonym verwendet. Zum Zusammenhang 
zwischen den Prinzipien bzw. Konzepten der Serviceorientierung und der Objektorien- 


tierung nimmt z. B. ERL Stellung. Vgl. Erl (2005), S. 321ff. 
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hat, welche Prinzipien als charakteristisch für eine SOA anzusehen sind.4!9 Wie 
die Autoren bemängeln, erweist sich eine Analyse der in den Beiträgen themati- 
sierten Designprinzipien als schwierig, da nicht nur verschiedene Designprinzi- 
pien thematisiert werden, sondern auch inhaltlich identische Prinzipien unter- 
schiedlich benannt werden.*!! Die nachfolgenden Ausführungen zu den De- 
signprinzipien einer SOA orientieren sich an den Ergebnissen der Literaturaus- 
wertung von HEUTSCHI/LEGNER/OSTERLE. Die in den untersuchten Beiträgen 
von den Autoren identifizierten Prinzipien werden zu drei übergeordneten 
Gruppen zusammengefasst, deren Vorstellung Gegenstand der Abschnitte 
3.3.2.1 bis 3.3.2.3 ist. 


3.3.2.1 Prinzip der „Abstraktion von der Implementierungslogik“ 


Das Gestaltungsprinzip der „Abstraktion von der Implementierungslogik“ ver- 
weist auf das im Rahmen einer SOA angestrebte Ziel, Dienste nutzen zu kön- 
nen, ohne Kenntnisse hinsichtlich ihrer Implementierung besitzen zu müssen. In 
Analogie zu dem aus der Objektorientierung bekannten Prinzip des Information 
Hiding®!2 wird von den bereitgestellten Services gefordert, Details der Service- 
implementierung wie beispielsweise die internen Datenstrukturen geheim zu 
halten.4!3 Das Verhalten eines Services lässt sich folglich als Black Box charak- 
terisieren, da die sich hinter dem Service verbergenden Implementierungsdetails 
für den Nutzer eines Dienstes unsichtbar bleiben und i. d. R. auch irrelevant 
sind.*14 

Das Designprinzip der „Abstraktion von der Implementierungslogik“ hat zur 
Folge, dass alle für die Nutzung eines Dienstes notwendigen Informationen in 
der Servicespezifikation enthalten sein müssen,?!5 die von der Serviceimple- 
mentierung getrennt ist.*16 Diesen Zusammenhang visualisiert Abbildung 16. 
Hierbei wird deutlich, dass der aufrufende Service A über die Schnittstelle des 


410 Vgl. Heutschi/Legner/Osterle (2006), S. 364f. 

411 Vgl. Heutschi/Legner/Österle (2006), S. 364. 

412 Zum Prinzip des Information Hiding vgl. z.B. Balzert (2001), S. 156; Fink/ 
Schneidereit/Voß (2005), S. 130; Pomberger/Pree (2004), S. 135. 

413 Vgl. Heutschi/Legner/Osterle (2006), S. 366. 

414 Vgl. Erl (2005), S. 298; Melzer et al. (2007), S. 13. 

415 In der Auswertung von HEUTSCHI/LEGNER/OSTERLE wird die Notwendigkeit zur Spezi- 
fizierung von Services als eigenes Designprinzip aufgenommen. Da die Servicespezifi- 
zierung einen Teilaspekt der Serviceabstraktion darstellt, wird das Designprinzip der 
Servicespezifizierung im Rahmen der Serviceabstraktion in Abschnitt 3.3.2.1 themati- 
sıert. 

416 Auf die Notwendigkeit, die Servicebeschreibung von der Serviceimplementierung zu 


separieren, verweisen beispielsweise Newcomer/Lomow (2005), S. 8f. 
Alexander Pastwa - 978-3-631-75488-7 


Downloaded from PubFactory at 01/11/2019 04:20:29AM 
via free access 


82 Services als Basiselemente einer SOA 


Dienstes B, die im Rahmen der Servicespezifikation beschrieben ist, dessen 
Funktionalität in Anspruch nehmen kann. 


Service A 
Schnitt- Implementierung 
stelle von À 


Service A 
nutzt 
Service B 


Service B 


Schnitt- Implementierung 
stelle vonB 


Abbildung 16: Aufruf eines Services?17 


3.3.2.2 Prinzipien der „hohen Servicekohäsion“ und der „schwachen lo- 
gischen Kopplung“ 


Mit den Prinzipien der „hohen Servicekohäsion“ und der „schwachen logischen 
Kopplung“ liegen zwei weitere Designprinzipien vor, die von HEUTSCHI/ 
LEGNER/ÖSTERLE im Rahmen ihrer Literaturauswertung genannt wurden. In ei- 
nem allgemeinen Verständnis setzt sich Kopplung (coupling) mit den Wechsel- 
beziehungen zwischen Softwarekomponenten auseinander, während die Kohä- 
sion (cohesion) ein Maß für die Abhängigkeit zwischen den Elementen inner- 
halb einer Softwarekomponente darstellt.*18 Als eine Softwarekomponente wird 


417 In Anlehnung an Tilkov/Starke (2007), S. 20. 

418 Vgl. Hansen/Neumann (2005), S. 225. Siehe hierzu auch die Beiträge von FINK/ 
SCHNEIDEREIT/VOß und LIEBHART, die in diesem Zusammenhang anstelle von Soft- 
warekomponenten den Modulbegriff verwenden. Vgl. Fink/Schneidereit/Voß (2005), 


S. 211; Liebhart (2007), S. 162. 
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dabei ein Stück Software bezeichnet, das über eine wohldefinierte Schnittstelle 
klar abgegrenzte Funktionen bereitstellt.4!9 

Aus der Perspektive der Serviceorientierung steht der Begriff der Serviceko- 
häsion für einen Indikator, der eine Aussage darüber zulässt, inwieweit die von 
einem Service gekapselten Funktionen und Daten dazu beitragen, einen im Vor- 
feld definierten Zweck zu erfiillen.42° Das Prinzip der „hohen Servicekohäsion“ 
schreibt in diesem Zusammenhang vor, dass ein Dienst möglichst nur diejeni- 
gen Funktionen und Daten kontrolliert, die zur Erfüllung einer logisch abge- 
grenzten und eigenständigen Aufgabe erforderlich sind.#2! 

Im Vergleich zum Prinzip der „hohen Servicekohäsion“ zielt das Prinzip der 
„schwachen logischen Kopplung“, das alternativ als Prinzip der losen Kopplung 
(loose coupling) bezeichnet werden kann, auf das Außenverhältnis der Soft- 
waredienste ab.422 In einer SOA steht der Begriff der Kopplung für die Stärke 
der Verbindung zwischen den zum Einsatz kommenden Diensten. Der Gegens- 
tandsbereich richtet sich folglich auf den Grad der Abhängigkeit zwischen Ser- 
viceangebot und -nachfrage. Für die Entwicklung von Services besitzt das Prin- 
zip der losen Kopplung insoweit eine Relevanz, als der Entwurf, die Implemen- 
tierung, die Architektur und die zum Einsatz kommende Technologie zur Ent- 
wicklung von Services von diesem Designprinzip betroffen sind.423 

Um einen erfolgreichen Betrieb einer SOA zu gewährleisten, wird angestrebt, 
eine möglichst schwache logische Kopplung zwischen den Services zu realisie- 
ren. D. h., die Kommunikation zwischen einem Service und seinen Nutzern 
zeichnet sich durch ein hohes Maß an Unabhängigkeit aus.424 Durch das Prinzip 
der losen Kopplung lassen sich mögliche Abhängigkeiten minimieren, die sich 
aufgrund einer räumlichen Verteilung zwischen dem Ort des Serviceangebots 
sowie dem Ort der Serviceinanspruchnahme ergeben können. Gleichzeitig stellt 
dieses Prinzip sicher, dass sich Services ungeachtet der Existenz einer im Vor- 
feld feststehenden Gruppe von Servicenehmern softwaretechnisch umsetzen 
und bereitstellen lassen. 

Trotz seiner mehrfachen Nennung in den von HEUTSCHI/LEGNER/OSTERLE 
ausgewerteten Literaturbeiträgen besteht hinsichtlich der Relevanz des Prinzips 
der losen Kopplung als wichtiges Charakteristikum einer SOA keine überein- 


419 Zum Begriff der Softwarekomponente vgl. Hansen/Neumann (2005), S. 225. 

420 Zu den verschiedenen Kohäsionsarten vgl. auch Müller (2007a), S. 94ff. 

421 Vgl. Heutschi/Legner/Osterle (2006), S. 367. 

422 Allgemein wird unter dem Begriff der Kopplung das Ausmaß verstanden, mit dem eine 
Komponente mit einer anderen interagiert. Vgl. Hansen/Neumann (2005), S. 225; 
Tilkov/Starke (2007), S. 18. Der allgemeine Charakter dieser Definition impliziert, dass 
die Kopplungseigenschaft nicht nur im Zusammenhang mit Services, sondern auch in 
Verbindung mit Datenstrukturen, Funktionen sowie Klassen diskutiert wird. 

423 Vgl. Wilms (2007), S. 566f. 


424 Vel. Herden et al. (2006), S. 52; Erl (2005), S. 291 und 297. 
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stimmende Meinung. Während z. B. für MAHLBERG, NEWCOMER/LOMOW sowie 
SCHELP/STUTZ das Designprinzip der losen Kopplung eine herausragende Be- 
deutung für die Gestaltung von Services einnimmt,425 weisen HEUTSCHI/ 
LEGNER/ÖSTERLE diesem Prinzip die Bedeutung einer anzustrebenden, aber 
keinesfalls notwendigen Eigenschaft von SOA zu.426 Einen Schritt weiter gehen 
in diesem Zusammenhang TILKOV/STARKE, deren Auffassung nach eine lose 
Kopplung mit Blick auf die Schwierigkeit, eine asynchrone Kommunikation 
bzw. Interaktion zu implementieren, nicht immer wünschenswert sei.427 Nach 
OESTEREICH steht lose Kopplung im Kontext einer SOA sogar für einen über- 
bewerteten und oft missverstandenen Mechanismus .*28 


3.3.2.3 Prinzip der „Verwendung technischer und offener Industriestan- 
dards“ 


Die Einhaltung der bereits thematisierten Gestaltungsprinzipien der Service- 
orientierung hängt maßgeblich mit der Frage zusammen, inwieweit diese tech- 
nisch umgesetzt werden können. Mit Blick auf diese Anforderung schreibt ein 
weiteres Gestaltungsprinzip vor, dass für die Entwicklung und die Nutzung von 
Services technische und offene Industriestandards einzusetzen sind, die eine 
hersteller- bzw. produktübergreifende Unterstützung erfahren. 

Einem allgemeinen Verständnis folgend, definieren Standards einheitliche 
Eigenschaften oder Regeln für Objekte, mit denen sich eine Vergleichbarkeit 
oder Kompatibilität herstellen lasst.429 Aus dem Blickwinkel der IS betrachtet, 
werden Standards mit dem Ziel eingesetzt, Kosten für den Informationsaus- 
tausch zu reduzieren, die infolge der Nutzung heterogener Rechnernetze, Be- 
triebssysteme, Benutzungsoberflächen und Anwendungssysteme entstehen.430 

Das Prinzip der technischen Standardisierung richtet sich auf die Bereitstel- 
lung einer geeigneten technischen Infrastruktur, mit deren Hilfe die im Rahmen 
einer SOA zu nutzenden Dienste entwickelt, veröffentlicht und aufgerufen wer- 
den können.43! Eine wichtige Aufgabe einer derartigen Infrastruktur liegt darin, 
die plattformspezifischen internen Datenformate und Kommunikationsprotokol- 
le in gemeinsame bzw. standardisierte Formate und Protokolle zu transferie- 


425 Vgl. Mahlberg (2007), S. 184; Newcomer/Lomow (2005), S. 75; Schelp/Stutz (2007), S. 
67. 

426 Vgl. Heutschi/Legner/Österle (2006), S. 368. 

427 Vgl. Tilkov/Starke (2007), S. 18. 

428 Vgl. Oesterreich (2007), S. 643. In seinem Beitrag liefert der Autor eine Gegen- 
überstellung der Anforderungen und Nachteile einer losen sowie festen Kopplung im 
Rahmen einer SOA. Vgl. Oesterreich (2007), S. 644. 

429 Vgl. Buxmann (2001), S. 544ff. 

430 Vgl. Buxmann (2001), S. 544. 


431 Vgl. Heutschi/Legner/Österle (2006), S. 366. 
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ren.#32 Darüber hinaus sorgen technische Standards dafür, dass die Dienste über 
eine einheitliche Schnittstellenbeschreibung verfügen. Neben der Betonung 
technischer Standards wird im Zusammenhang mit der softwaretechnischen 
Umsetzung einer SOA insbesondere der Einsatz von offenen Standards propa- 
giert, die von entsprechenden Non-Profit-Organisationen vorgeschlagen sowie 
weiterentwickelt werden. Offene Standards zeichnen sich dadurch aus, dass sie 
nicht der Marktmacht einer bestimmten Organisation unterliegen, i. d. R. ent- 
geltlos oder eventuell über eine nominelle Gebühr genutzt werden können und 
je nach Anwendungsbereich beliebig erweiterbar sind.*33 

Zusammenfassend ist zu konstatieren, dass die in den vorangegangenen Aus- 
führungen präsentierten Designprinzipien der Serviceorientierung keinesfalls 
unabhängig voneinander zu betrachten sind. Vielmehr bedingt die Existenz ei- 
nes Prinzips das Vorhandensein eines weiteren.434 Exemplarisch ist der Zu- 
sammenhang zwischen dem Prinzip der Serviceabstraktion und dem Prinzip der 
losen Kopplung zu nennen.#35 Hierbei sind die Existenz einer Servicespezifika- 
tion sowie die damit zusammenhängende Erfüllung des Prinzips der Serviceabs- 
traktion Voraussetzung dafür, dass sich eine lose gekoppelte Kommunikation 
zwischen den Diensten realisieren lässt.436 


3.3.3 Rollenkonzept einer SOA 


In den bisherigen Ausführungen blieb unberücksichtigt, auf welche Weise sich 
die Dienste in einer SOA nutzen lassen und welche Akteure dabei beteiligt sind. 
Damit Services in einer SOA angeboten, gefunden und schließlich genutzt wer- 
den können, ist das Zusammenspiel diverser Rollen von Bedeutung.#37 Die im 
Rahmen einer SOA anfallenden Rollen und die zwischen diesen existierenden 
Kommunikationsbeziehungen lassen sich anhand des Rollenkonzepts einer 
SOA verdeutlichen, das in Abbildung 17 veranschaulicht ist.438 


432 Vgl. Heutschi/Legner/Österle (2006), S. 366. 

433 Charakterstisch für einen offenen Standard ist darüber hinaus, dass dieser das Ergebnis 
eines Abstimmungsprozesses darstellt und vor seiner Nutzung beliebig vervielfältigt 
werden kann. Zu den Eigenschaften offener Standards vgl. Heutschi/Legner/Österle 
(2006), S. 367. 

434 Eine Übersicht zu den vielfältigen Beziehungsstrukturen der für ihn relevanten Prinzi- 
pien einer SOA liefert Erl (2005), S. 312ff. 

435 Vgl. hierzu die Abschnitte 3.3.2.1 und 3.3.2.2. 

436 Vgl. hierzu auch Newcomer/Lomow (2005), S. 75. 

437 Vgl. Melzer et al. (2007), S. 7. 

438 Zum Zusammenspiel von Dienstanbieter, Dienstnutzer und Dienstverzeichnis vgl. 


Specht/Weisbecker/Spath (2006), S. 12. 
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Dienst- 
verzeichnis 


3 Verweis auf 
1 Veröffentlichen Dienst 
2 Suchen 


4 Abfrage der Beschreibung 
Dienst- q— | Dienst- 
anbieter —_ — — nutzer 
5 Nutzung 


Abbildung 17: Rollenkonzept einer SOA #39 


Wie aus dieser Abbildung hervorgeht, ist die Existenz eines Serviceanbieters 
von Bedeutung, der einem Servicenehmer einen Dienst oder mehrere Dienste 
zur Nutzung zur Verfügung stellt. Alternativ wird der Serviceanbieter auch als 
Service Provider bezeichnet. Die Aufgabe des Serviceanbieters liegt darin, eine 
geeignete Plattform zur Verfügung zu stellen, die einen Zugriff auf die von ihm 
veröffentlichten Dienste ermöglicht. Dabei ist es nicht erforderlich, dass der 
Service Provider die von ihm angebotenen Services selbst entwickelt. Alternativ 
kann ein Service Provider Dienste anbieten, die von einem dritten Akteur ent- 
wickelt wurden. 

Für den Servicenehmer, der den bereitgestellten Dienst nachfragt, haben sich 
auch die Termini Servicenutzer, Servicekonsument und Service Requestor 
durchgesetzt. Der Service Requestor lässt sich mit dem Client in einer Client- 


439 In Anlehnung an Melzer et al. (2007), S. 12. 

440 In den Aufgabenbereich des Serviceanbieters fallen darüber hinaus die Aufrechterhal- 
tung des Betriebs der Plattform und damit auch die Verfügbarkeit des Dienstes. Darüber 
hinaus ist vom Serviceanbieter Sorge zu tragen, dass die Sicherheit der Plattform ge- 
währleistet ist. Dazu gehören Aufgaben zur Einrichtung der Authentifizierung und Au- 


thentisierung der Service. 
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Server-Architektur vergleichen, der im Rahmen einer kooperativen Aufgaben- 
abwicklung Funktionalitäten nutzt, die von einem Server erbracht werden.“4! 

Damit sich die angebotenen Dienste von dem Servicenehmer auffinden las- 
sen, wird mit dem Serviceverzeichnis, das auch als Service Broker oder Service 
Registry bezeichnet wird, eine weitere Rolle dazwischengeschaltet, die sowohl 
der Registrierung als auch dem Auffinden der Services dient. Um ein schnelles 
Auffinden der Dienste zu ermöglichen, ist es erforderlich, die Services in ent- 
sprechende Kategorien einzuordnen. In diesem Zusammenhang ist es möglich, 
dass eine Unternehmung, die sich für eine SOA entscheidet, mehrere Verzeich- 
nisse betreiben kann. In einer derartigen Konstellation ließe sich ein Verzeich- 
nis ausschließlich für die unternehmungsinterne Nutzung von Services einset- 
zen, während ein zweites Verzeichnis für die Registrierung und für das Auffin- 
den von Diensten verwendet wird, die von Nutzern aufgerufen werden, die sich 
außerhalb der SOA-betreibenden Unternehmung befinden. 

Für den Aufruf eines Services ist eine Reihe von Aktionen zu durchlaufen.442 
Damit ein Dienst von den potenziellen Nutzern gefunden werden kann, ist es im 
ersten Schritt notwendig, den Dienst in einem Serviceverzeichnis zu registrie- 
ren.443 Für diesen Zweck ist vom Anbieter des Services eine Servicespezifikati- 
on zu erstellen, die im nächsten Schritt im Verzeichnis veröffentlicht wird (1). 
Möchte ein potenzieller Dienstnutzer einen Service in Anspruch nehmen, sucht 
er anhand der in dem Verzeichnis existierenden Kriterien nach einem geeigne- 
ten Dienst (2). Erscheint ein Service als geeignet, erhält der potenzielle Servi- 
cenutzer die Adresse bzw. den Verweis auf die Servicespezifikation des von 
ihm nachgefragten Dienstes (3).444 Für diesen Zweck ist es wichtig, dass Stan- 
dards eingehalten werden, die es dem Servicekonsumenten ermöglichen, auf die 
Schnittstellenbeschreibung des zu nutzenden Dienstes zuzugreifen (4).445 Unter 
Nutzung der Servicespezifikation lässt sich im letzten Schritt der betreffende 
Dienst aufrufen (5). 


3.4 Web Services zur Implementierung Serviceorientierter Anwendungen 


Neben SOA stellen auch die Web Services seit einigen Jahren einen viel beach- 
teten Begriff in der Informatikliteratur dar. Unter den verschiedenen Mög- 
lichkeiten zur Implementierung Serviceorientierter Anwendungen, d.h. von 
Anwendungen, die auf einer SOA basieren, wird insbesondere der Einsatz von 


441 Zum Client-Server-Konzept vgl. Fink/Schneidereit/VoB (2005), S. 43f. 
442 Vgl. Melzer et al. (2007), S. 16. 

443 Dafür ist es erforderlich, dass dieser Dienst bereits erstellt worden ist. 
444 Vgl. Hammerschall (2005), S. 118. 

445 Vgl. Hammerschall (2005), S. 117. 


446 Vgl. Eymann/Winter (2008), S. 70. 
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Web Services als zukunftsweisend eingeschätzt.’ Zunächst wird in Abschnitt 
3.4.1 ein grundlegendes Verständnis zur Technologie der Web Services präsen- 
tiert.448 Um Web Services im Rahmen einer SOA zu nutzen, sind verschiedene 
Standards einzusetzen. Abschnitt 3.4.2 widmet sich den Bausteinen der Web 
Service-Technologie. 


3.4.1 Grundverständnis zum Begriff des Web Services 


Bisher ist es den Autoren der zahlreichen Publikationen nicht gelungen, die ver- 
schiedenen Vorschläge zur Definition von Web Services zu einem einheitlichen 
Begriffsverständnis zu vereinen. Mit Blick auf seinen integrierten und um- 
fassenden Charakter zur Begriffsbestimmung eines Web Dienstes orientiert sich 
die vorliegende Arbeit an dem Definitionsvorschlag des Arbeitskreises ENT- 
WICKLUNG WEB-SERVICEBASIERTER ANWENDUNGEN DER GESELLSCHAFT FÜR IN- 
FORMATIK (GI).459 Dem Arbeitskreis zufolge handelt es sich bei Web Services 
um „selbst-beschreibende, gekapselte Softwarekomponenten, die eine Schnitt- 
stelle anbieten, über die ihre Funktionen entfernt aufgerufen und die lose durch 
den Austausch von Nachrichten miteinander gekoppelt werden können. Zur Er- 


447 Vel. hierzu Hofmann (2003), S. 27 und 28; Richter/Haller/Schrey (2005), S. 414. 
MELZER ET AL. bemerken in diesem Zusammenhang, dass die Entwicklung von Web 
Services maßgeblich das Interesse an SOA begünstigt habe. Vgl. Melzer et al. (2007), S 
337. BEIMBORN/WEITZEL stufen Web Services sogar als eine technische Revolution ein. 
Vgl. Beimborn/Weitzel (2003), S. 1360. Die Erwartungshaltung an Web Services wird 
auch bei ALT/HEUTSCHVÖSTERLE deutlich, die bemerken, dass Web Services als neue 
Zauberformel für die Integration von IS nach dem Vorbild einer „Lego-Wirtschaft“ gel- 
ten. Vgl. Alt/Heutschi/Österle (2003), S. 63. Damit spielen die Autoren auf den Modul- 
charakter von Web Services an. 

448 Mit Blick auf die bei GABRIEL/BEIER diskutierte Abgrenzung der Begriffe „Technik“ 
und „Technologie“ wird in dieser Arbeit die Auffassung vertreten, bei Web Services 
handele es sich um eine Technologie. GABRIEL/BEIER führen in diesem Zusammenhang 
aus, dass eine Technologie neben der Technik auch die Anwendungs- und Nutzungspro- 
zesse in Bezug auf die Technik umfasst. Vgl. Gabriel/Beier (2003), S. 84. Da Kenntnis- 
se zur Nutzung von Web Services bekannt sind und auch in dieser Arbeit thematisiert 
werden, wird im Folgenden von der Web Service-Technologie gesprochen. Damit folgt 
diese Arbeit der Einschätzung weiterer Autoren. Zu diesen gehören z. B. Frotscher 
(2007), S. 489; Rebstock/Lipp (2003), S. 294; Oehler (2006), S. 106. 

449 Vgl. Kossmann/Leymann (2004), S. 119. Auf die mannigfaltigen Versuche, Web Servi- 
ces zu definieren, und die daraus resultierende Konfusion verweist KÜSTER, indem er 
schreibt: „Wie bei allen schillernden Schlagworten bedeutet Web-Service für jeden et- 
was anderes und meistens etwas von allem“. Küster (2003), S. 6. 

450 Mit Blick auf die bisher erfolgte synonyme Verwendung der Begriffe „Services“ und 
„Dienste“ werden im weiteren Verlauf dieser Arbeit zur Vermeidung einer sprachlichen 


Monotonie die Termini „Web Dienste“ und „Web Services“ genutzt. 
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reichung universeller Interoperabilität werden für die Kommunikation die her- 
kömmlichen Kanäle des Internets verwendet“.#5! 

Wie aus diesem Definitionsansatz deutlich wird, verfügt ein Web Service 
über all diejenigen Eigenschaften eines Dienstes, die bereits in Abschnitt 3.3.1 
thematisiert wurden. Web Services bieten für ihren Aufruf sowohl eine Schnitt- 
stelle als auch die softwaretechnische Realisierung der von ihnen bereitgestell- 
ten Funktionalität. Weiterhin werden von einem Web Service die in Abschnitt 
3.3.2 präsentierten Gestaltungsprinzipien untersttitzt.452 Die Eigenschaft der 
Selbstbeschreibung deutet auf die Erfüllung des Prinzips der „Abstraktion von 
der Implementierung“. Übertragen auf den Einsatz von Web Services besagt 
dieses Prinzip, dass es für den Aufruf eines Web Services ausreicht, nur die im 
Vorfeld angelegten Beschreibungsmerkmale eines Web Dienstes wie Name, 
Funktionsbeschreibung, Dienstgüte etc. auszuwerten. Darüber hinaus folgen 
Web Services dem Prinzip der losen Kopplung, indem sie sich aufrufen lassen, 
ohne dass ihre Nutzer über Kenntnisse über die technische Realisierung des 
Dienstes verfügen müssen. In diesem Zusammenhang verweist die Eigenschaft 
der Kapselung darauf, dass ein Web Service eine unabhängige und in sich abge- 
schlossene Programmeinheit darstellt, die eine klar umrissene Aufgabe erfüllt. 


3.4.2 Bausteine einer Web Serviceorientierten Anwendung 


Zur Implementierung und Nutzung von Web Services konkurrieren derzeit eine 
Reihe unterschiedlicher Konzepte, Protokolle und Modelle, die infolge der 
Standardisierungsbestrebungen des WORLD WIDE WEB CONSORTIUM (W3C)#53 
sowie der ORGANIZATION FOR THE ADVANCEMENT OF STRUCTURED INFORMATI- 
ON STANDARDS (OASIS)*54 entstanden sind sowie weiterentwickelt werden.*> 
Trotz der Heterogenität der zum Teil miteinander konkurrierenden Web Servi- 
ce-Standards ist zu konstatieren, dass die im Rahmen des Einsatzes von Web 
Services angestrebte Kommunikation zwischen den im Internet verteilten An- 


451 Vgl. Herden et al. (2006), S. 69. 

452 Siehe hierzu die Prinzipien bzw. Konzepte zur Gestaltung von Diensten in Ab- 
schnitt 3.3.2. 

453 Zur Entstehung sowie zum Aufgabenbereich des W3C vgl. W3C (2009); Klettke/Meyer 
(2003), S. 20. 

454 Zum Aufgabengebiet des Konsortiums vgl. OASIS (2008). 

455 Vgl. Herden et al. (2006), S. 69. Während sich die Forschungsaktivitäten des W3C- 
Konsortiums auf die Weiterentwicklung horizontaler bzw. industrieunabhängiger Stan- 
dards richten, fokussiert OASIS die Entwicklung sowie Verbesserung vertikaler Stan- 
dards. Vgl. Bettag (2001), S. 303. KÜSTER bemängelt in diesem Zusammenhang eine 
„kaum mehr überschaubare Anzahl von Web-Service-Standards mit unterschiedlichen 


Zielsetzungen“. Küster (2003), S. 6. 
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wendungen bzw. Objekten auf wenigen Grundlagenstandards basiert.456 Die 
Vorstellung dieser Standards ist Gegenstand der folgenden Ausführungen. 
Hierzu werden die Web Service-Standards SOAP (Abschnitt 3.4.2.2), WSDL 
(Abschnitt 3.4.2.2) und UDDI (Abschnitt 3.4.2.3) als wichtigste Bausteine einer 
Web Serviceorientierten-Anwendung thematisiert. 


3.4.2.1 Nachrichtenaustausch mit SOAP 


Eine wichtige Voraussetzung fiir den erfolgreichen Aufbau einer SOA ist die 
Integration von Services.457 Damit sich Services aufrufen lassen, muss ein ge- 
eignetes Protokoll zur Kommunikation mit den Diensten zur Verfügung stehen. 
Bei SOAP458 handelt es sich um ein Standardformat für die Übertragung von 
Nachrichten.459 Ein SOAP-Dokument gibt die Struktur der Nachrichten vor, in 
der der Aufruf an einen Web Service mit den benötigten Parametern spezifiziert 
ist. Handelt es sich um eine Antwortnachricht, enthält ein SOAP-Dokument die 
Ergebnisdaten.*60 Zur Repräsentation der Daten kommt XML zum Einsatz, wo- 
bei zur Definition der Datentypen das standardisierte XML-Schema des W3C 
verwendet wird.46! 

Damit der Zugriff auf einen Web Service sowie ein Nachrichtenaustausch 
zwischen zwei Web Services auf Basis von XML und tiber das Internet erfolgen 
kann, müssen geeignete Träger- bzw. Verpackungsprotokolle für den Nachrich- 
tenaustausch zur Verfügung gestellt werden. Zur Übertragung der Daten werden 
folglich gängige Internetprotokolle wie beispielsweise Hypertext Transfer Pro- 
tocol (HTTP), File Transfer Protocol (FTP), Simple Mail Transfer Protocol 
(SMTP) und Transmission Control Protocol (TCP) verwendet.462 Aufgrund sei- 


456 Vgl. hierzu Küster (2003), S. 6f.; Leyking/Ziemann/Loos (2006), S. 1037. 

457 Vgl. Siebenhaar et al. (2008), S. 327. 

458 Nachdem zu Beginn der Web Service-Technologie SOAP als Akronym für die Bezeich- 
nung Simple Object Access Protocol diente, wird der Terminus SOAP heute nur noch 
als Eigenname verwendet. Vgl. Küster (2003), S. 7. 

459 Vgl. Mintert (2005), S. 64; Leser/Naumann (2007), S. 405. Als Nachfolger des Middle- 
ware-Protokolls XML-RPC wurde SOAP im Jahr 2000 von MICROSOFT entwickelt. Vgl. 
Hammerschall (2005), S. 112. Daraufhin erfolgte eine Weiterentwicklung von namhaf- 
ten Firmen wie beispielsweise MICROSOFT, HP, SAP und IBM. 

460 Vgl. Hammerschall (2005), S. 118. 

461 Daneben sind auch die Erstellung und der Einsatz eigener Datentypen möglich. 

462 Vgl. Rebstock/Lipp (2003), S. 295. Der Einsatz etablierter Protokolle wie HTTP er- 
leichtert die Übertragung von Nachrichten über Firewalls hinweg. Unter den Transport- 
protokollen wird dabei HTTP favorisiert. Vgl. Hammerschall (2005), S. 118. Bei der 
Datenübertragung über SOAP lassen sich mit dem Remote Procedure Call (RPC) und 
Document zwei Arten unterscheiden. Vgl. Küster (2003), S. 7. Während Document die 
Übertragung einer einzelnen Nachricht ermöglicht, handelt es sich bei RPC um einen 


entfernten Funktionsaufruf. 
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nes XML-Bezugs ist SOAP ebenfalls unabhängig von der Plattform und der 
verwendeten Programmiersprache. Durch SOAP können nicht nur einzelne Pa- 
rameter übergeben werden, sondern auch beliebige XML-Dokumente ausge- 
tauscht werden.463 


Dienstabnehmer Dienstanbieter 


Netzwerk- Netzwerk- 
Protokoll Protokoll 


Anfrage 


Abbildung 18: Aufruf eines Web Services 


Zur Durchführung der Kommunikation kommt beispielsweise das Request- 
Response-Konzept zum Einsatz. Wie in Abbildung 18 verdeutlicht wird, sendet 


463 Vgl. Küster (2003), S. 7. 
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der Dienstabnehmer unter Verwendung von HTTP einen Aufruf (Request), der 
auch als SOAP-Message bezeichnet wird, an eine Zielanwendung.*6 

Das SOAP-Dokument enthält eine Beschreibung, welche Funktionen auf der 
Zielanwendung vorliegen müssen. Das SOAP-Dokument kommt zum Einsatz, 
um alle relevanten Daten, die zur Anwendung der Funktion benötigt werden, an 
die Zielapplikation zu senden (1). Die im Rahmen der SOAP-Nachricht gekap- 
selten Eingabeparameter werden von dem Web Service entpackt und an die je- 
weilige Anwendung weitergegeben (2). Nachdem die Eingabeparameter verar- 
beitet sind, wird das Ergebnis in Form einer SOAP-Antwort an den Sender zu- 
rückgeschickt (3). Dieser Teil der Kommunikation bildet den Response-Teil des 
Web Services. Im Anschluss wird das Ergebnis beim Dienstnehmer wieder ent- 
packt (4). 

Da es sich bei SOAP um ein XML-Dokument handelt, können die Bestand- 
teile einer SOAP-Nachricht als Elemente bezeichnet und in Form einer ge- 
schachtelten Struktur angeordnet werden. Eine SOAP-Nachricht kann aus dem 
Envelope-, dem Header-, dem Body- sowie noch weiteren selbstdefinierten 
Elementen bestehen. Wie aus der Abbildung 19 hervorgeht, bildet das SOAP- 
Envelope-Element das übergeordnete Element bzw. das Wurzelelement, inner- 
halb dessen die eigentliche SOAP-Nachricht eingebettet ist. Das Envelope- 
Element definiert den XML-Namensraum des Dokuments und beinhaltet neben 
dem Body- und optionalen Header-Element noch weitere benutzerdefinierte 
Elemente. 

Das SOAP-Header-Element als untergeordnetes Element beschreibt die Me- 
tadaten einer Nachricht. Die darin enthaltenen Angaben informieren über das 
Routing, das verwendete Verschlüsselungsverfahren oder über die Herkunft der 
Nachricht.465 Ebenso lassen sich im Header-Element Meldungen einbetten, die 
im Fall einer fehlerhaften oder unvollständigen Datenübergabe aufgerufen wer- 
den. Im SOAP-Body werden alle Informationen untergebracht, die ein Web 
Service zur Aufgabenerfüllung benötigt. Folglich enthält der SOAP-Body bei- 
spielsweise den Namen der aufrufenden Funktion sowie die zur Aufgabenerfül- 
lung notwendigen Daten. Handelt es sich um einen Methodenaufruf, so enthält 
der Body einer SOAP-Nachricht die erforderlichen Eingabeparameter. Bei einer 
Antwort sind im Body-Element die Rückgabedaten aufgeführt. 


464 Das im Folgenden beschriebene Verfahren bietet nicht nur das Potenzial, eine rechner- 
gestützte Kommunikation zwischen zwei Applikationen herzustellen, sondern eröffnet 
auch die Möglichkeit, mehrere Applikationen eines Zielsystems über einen Request an- 
zusprechen. Zu diesem Zweck werden die Daten eines SOAP-Dokuments je nach Inhalt 
in entsprechende Methodenaufrufe transformiert. Die Verarbeitungsergebnisse der auf- 
gerufenen Methoden lassen sich beispielsweise in einem Servlet bündeln und mit dem 
in diesem Abschnitt beschriebenen Übertragungsverfahren an die Quellanwendung 
übermitteln. 


465 Vgl. Küster (2003), S. 8. 
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SOAP-Nachricht 


SOAP-Envelope 
SOAP-Header 


Optionale Informationen 


SOAP-Body 


Name der 
aufzurufenden 
Funktionen und 

Nutzdaten 


Abbildung 19: Struktur einer SOAP-Nachricht 


3.4.2.2 Schnittstellendefinition mit WSDL 


Wie beim Prinzip der „Abstraktion von der Implementierung“ deutlich wurde, 
ist die Beschreibung einer standardisierten, maschinenverständlichen Schnitt- 
stelle eine zentrale Voraussetzung für den Informationsaustausch zwischen ei- 
nem Service-Nachfrager und einem -Anbieter. Um Web Services nutzen zu 
können, muss daher gewährleistet sein, dass die Dienste in einer angemessenen 
Weise spezifiziert und ihre Schnittstellen nach außen hin offen gelegt sind.466 
Im Rahmen der Spezifikation von Web Services ist beispielsweise festzulegen, 
über welche Methoden bzw. Funktionen ein Web Service verfügt, so dass der 
Aufruf einer anfragenden Instanz verarbeitet und in Form eines Ergebnisdoku- 
ments zurückgegeben werden kann. 

Diese Aufgabe wird von einer Beschreibungs- bzw. Definitionskomponente 
übernommen, die den zweiten Baustein einer Web Serviceorientierten Anwen- 


466 Vgl. Küster (2003), S. 9. 
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dung repräsentiert. Der für diesen Zweck vom W3C entwickelte XML-Standard 
trägt die Bezeichnung Web Services Description Language (WSDL;).467 Seit ih- 
rem Erscheinen im Jahr 2000 hat sich WSDL heute als De-facto-Standard bei 
der Nutzung von Web Services etabliert.468 Mit Hilfe dieses Standards lässt sich 
eine Schnittstellenbeschreibung erstellen, in der alle für einen Serviceaufruf 
notwendigen technischen Informationen abgelegt werden, die von einem Client 
für einen Aufruf des Dienstes benötigt werden.49 


<definitions> 


<types> ... <types> 
<message name= "Message1" >...</message> es 


<portType>...</portType> 


<binding>...</binding> 


Konkreter 
<service>...</service> Teil 


<definitions> 


Abbildung 20: Aufbau eines WSDL-Dokuments 


Anhand der Abbildung 20 lassen sich die wichtigsten Konzepte sowie die 
Struktur einer WSDL-Schnittstellenbeschreibung veranschaulichen. Wie in der 
Abbildung zu erkennen ist, besteht ein WSDL-Dokument sowohl aus einem 
abstrakten als auch einem konkreten Teil. Während das types-Element, die mes- 
sage-Elemente sowie das portType-Element für den abstrakten Teil eines 
WSDL-Dokuments stehen, handelt es sich bei dem binding-Element und dem 
service-Element um Vertreter des konkreten Teils einer WSDL-Datei.?70 

Das definitions-Element ist das Wurzelelement eines WSDL-Dokuments. In- 
nerhalb des definitions-Elements werden der Name und der Namensraum des 
Web Services sowie der Namensraum der verwendeten Standards als Attribut- 


467 Vgl. Beimborn/Mintert/Weitzel (2002), S. 278. 

468 Dass WSDL die am weitesten verbreitete Definitionssprache im Web Service-Umfeld 
ist, wird deutlich bei Stiemerling (2002), S. 439. Der Ursprung von WSDL datiert auf 
das Jahr 2000, als im September dieses Jahres WSDL von den Unternehmungen ARIBA, 
IBM und MICROSOFt präsentiert wurde. Vgl. Küster (2003), S.9. Während WSDL als 
Candidate Recommendation bereits in der Version 2.0 existiert, erfolgt eine produktive 
Verwendung heute auf Basis der Version 1.1. 

469 Vgl. Leser/Naumann (2007), S. 405. Wie in der Literatur üblich, werden im Folgenden 
die Begriffe WSDL-Datei und WSDL-Dokument synonym verwendet. 


470 Vgl. Liebhart (2007), S. 16. 
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werte festgelegt. Die Aufgabe des types-Elements liegt darin, alle Datentypdefi- 
nitionen festzulegen, die zum Austausch der Nachrichten bzw. der messages er- 
forderlich und nicht im W3C-Standard zum XML-Schema enthalten sind.47! In- 
nerhalb der message-Elemente werden die Nachrichten festgelegt, die bei einem 
SOAP-Aufruf übertragen werden. Hierbei ist für jede Anfrage sowie Antwort 
eine separate Nachricht zu definieren.472 

Mit Hilfe des portType-Elements lassen sich alle Operationen beschreiben, 
die der Web Service anbietet.473 Die Methoden werden in einem gesonderten 
Element mit der Bezeichnung operations definiert. Dabei unterstützt WSDL 
vier Nachrichtentypen.474 Als Alternativen stehen die Nachrichtentypen One- 
Way, Request-Response, Solicit-Response und Notification zur Verfügung. Der 
One-Way-Nachrichtentyp ist dadurch gekennzeichnet, dass ein Web Service 
nach dem Eintreffen einer Nachricht des Client nicht antwortet, während beim 
Request-Response dies der Fall ist. Im Rahmen des Solicit-Response sendet der 
Server eine Nachricht an den Client, worauf von diesem eine Antwort folgt. 
Beim Notification-Nachrichtentyp wird hingegen eine Antwort des Client nicht 
erwartet. 

Das binding-Element als Konzept des konkreten Teils einer WSDL- 
Schnittstellenbeschreibung wird genutzt, um das Nachrichtenformat und das 
Transportprotokoll vorzugeben, das für die Übertragung der Aufrufe zum Ein- 
satz kommt.475 Im Rahmen des service-Elements werden Informationen aufge- 
führt, die für den Zugriff auf den Web Service notwendig sind. Die Informatio- 
nen betreffen z.B. Angaben zur verwendeten Netzwerkadresse sowie Port- 
nummer. 


3.4.2.3 Veröffentlichung mit UDDI 


Damit ein Web Service von möglichst vielen Servicenehmern genutzt werden 
kann, ist eine geeignete Plattform bereitzustellen, mittels dieser sich Web Servi- 
ces in einem Netzwerk bekannt machen und auffinden lassen.476 Diese Aufga- 
ben werden von einem Verzeichnisdienst mit der Bezeichnung Universal Desc- 


471 Dies hat zur Folge, dass sich für den jeweiligen Web Service zugeschnittene Datentypen 
nutzen lassen, die mit Hilfe der Datentypen des XML-Schemas erstellt werden. 

472 Erfordert der Web Service einen Eingabeparameter, der nach seiner Verarbeitung zu ei- 
nem Rückgabewert führt, sind folglich zwei Nachrichten zu definieren. 

473 Vgl. Reinefeld/Schintke (2004), S. 131. 

474 Vgl. hierzu Hammerschall (2005), S. 116; Liebhart (2007), S. 17. Welcher Nachrichten- 
typ zum Einsatz kommt, hängt von der Reihenfolge der messages ab. Folgt einem input- 
Element ein output-Element, deutet dies auf einen Request-Response-Nachrichtentyp. 
Liegt nur ein input-Element vor, handelt es sich um einen One-Way-Nachrichtentyp. 

475 Als Bindungen kommen neben SOAP auch HTTP GET sowie HTTP POST in Frage. 


476 Vgl. Brehm/Haak/Gömez (2008), S. 493. 
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ription, Discovery and Integration (UDDI) erfüllt, der den dritten Baustein einer 
Web Serviceorientierten Anwendung darstellt” Von einem UDDI- 
Verzeichnisdienst werden zwei Funktionen bereitgestellt.478 Zum einen lassen 
sich mit Hilfe eines UDDI-Verzeichnisdienstes Web Services registrieren.479 
Zum anderen stellt ein Verzeichnisdienst einen Zugriffsmechanismus zur Ver- 
fügung, der es ermöglicht, einen Dienst für eine potenzielle Nutzung aufzufin- 
den.489 In diesem Zusammenhang werden einerseits direkte Suchanfragen un- 
terstützt, die durch die Eingabe eines oder mehrerer Schlagworte ausgelöst wer- 
den können. Andererseits können Web Services anhand von Klassifikationska- 
tegorien aufgefunden werden, indem der Nutzer eines UDDI in einer vom 
Betreiber des Verzeichnisdienstes vorab definierten Aufteilung bzw. Systemati- 
sierung der angebotenen Dienste nach dem Vorbild eines Drill-Down navigie- 
ren kann.48! 

Die Katalogisierung der in einem UDDI registrierten Web Services erfolgt 
nach dem Vorbild eines Branchenbuchs.482 Die Verzeichnisse sind dabei in drei 
Bereiche aufgeteilt, die als White Pages, Yellow Pages und Green Pages be- 
zeichnet werden.483 In Anlehnung an das Branchenverzeichnis GELBE SEITEN 
beschreiben die Yellow Pages eine Gruppe von Services und klassifizieren die- 
se anhand von Industriezweigen. Yellow Pages erlauben die Suche über 
Schlagwörter oder durch einen Zugriff auf die Klassifikationskategorien.484 
Green Pages informieren über die technische Ausgestaltung eines angebotenen 
Web Services. I.d.R. wird auf die dazugehörende WSDL-Datei verwiesen. 
Ferner sind Informationen zum Geschäftsmodell einer Unternehmung diesem 
Informationsbereich zugeordnet. In den White Pages sind alle Angaben enthal- 
ten, um mit einem Dienstanbieter interagieren zu können. Neben einem Na- 
mensregister führen White Pages Kontaktinformationen der Service Provider 


477 Vgl. Beimborn/Weitzel (2003), S. 1362f. Die Bezeichnung UDDI geht auf den Namen 
eines Projekts zurück, das von den Softwarefirmen MICROSOFT und IBM initiiert wurde. 
Als Ziel dieses Projekts wurde die Implementierung eines globalen, standardisierten 
Verzeichnisses zum Auffinden von Web Services definiert. 

478 Vgl. hierzu Hammerschall (2005), S. 117; Brehm/Haak/Gomez (2008), S. 493. 

479 Der UDDI-Standard sieht in diesem Zusammenhang eine entsprechende Application 
Programming Interface (API) vor. 

480 In Anlehnung an die API zum Auffinden von Web Services definiert der UDDI- 
Standard ebenfalls eine Inquiry-API. Als alternativer Standard für das Auffinden von 
Web Services lässt sich die Web Service Inspection Language (WS-Inspection) nutzen. 
Eine Vorstellung dieses Standards liefern Ballinger et al. (2001) und Brittenham (2002). 

481 Vgl. Küster (2003), S. 10. 

482 Vgl. Kossmann/Leymann (2004), S. 122. 

483 Vgl. Bettag (2001), S. 304. 

484 Als gebräuchlichste Klassifikationsschemata können entweder das North American In- 
dustry Classification System (NAICS) oder die Universal Standard Products and Servi- 


ces Codes (UNSPSC) zur Anwendung kommen. Vg l. ln 003), S. 10. 
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auf und ähneln damit einem Telefonbuch.485 Darüber hinaus liefern die White 
Pages weitere Identifikationsmerkmale wie die Data Universal Numbering Sys- 
tem-Nummer (DUNS), die zur eindeutigen Identifizierung von Unternehmun- 
gen genutzt wird. 

Die Struktur und die Funktionalität eines Verzeichnisdienstes sind in einem 
UDDI-Schema spezifiziert. Das Schema definiert das Modell aller Entitäten, die 
zur Beschreibung der in einem UDDI-Verzeichnisdienst angebotenen Web Ser- 
vices verwendet werden können. Von Bedeutung sind dabei folgende Entitä- 
ten.486 Mit Hilfe der businessEntity wird die Unternehmung oder die Geschäfts- 
einheit beschrieben, die den Web Service anbietet. Darüber hinaus wird diese 
Entität verwendet, um einen Web Service im Verzeichnisdienst anzumelden. 
Dies erfolgt, indem eine neue businessEntity erstellt wird, der im zweiten 
Schritt die WSDL-Schnittstellenbeschreibung des jeweiligen Services zugeord- 
net wird. Die businessService-Entität dient zur Beschreibung einer Menge zu- 
sammengehörender Web Services, die von einer businessEntity angeboten wer- 
den. Die Entität bindingTemplate enthält die technischen Informationen, die für 
den Zugriff auf einen Web Service notwendig sind. Unter Einsatz von tModel 
(taxonomy model) werden die businessEntities und businessServices kategori- 
siert. Für diesen Zweck definieren tModels eine Taxonomie im Verzeichnis- 
dienst, in der businessEntities und businessServices abgelegt und gefunden 
werden können. 

Der UDDI-Verzeichnisdienst lässt sich einsetzen, um private Verzeichnisse 
zu implementieren, die beispielsweise auf eine unternehmungsinterne Anwen- 
dung der angebotenen Dienste ausgelegt sind. Gleichzeitig haben Web Service- 
Anbieter auch die Möglichkeit, ihre Dienste in ein öffentliches Verzeichnis ein- 
zutragen, damit diese von einem möglichst großen Anwenderkreis genutzt wer- 
den k6nnen.48? Als letzte Variante sind Zwischenformen denkbar, bei denen 
Web Services sich in branchenspezifischen, semi-dffentlichen Verzeichnissen 
registrieren lassen.488 


3.5 Zusammenfassung und Ableitung eines integrierten SOA- 
Verständnisses 


Die Ausführungen des vorliegenden Kapitels hatten zum Ziel, grundlegende 
konzeptionelle und technische Facetten zum derzeit intensiv diskutierten Ansatz 
einer SOA darzustellen. Ausgehend vom Begriff der integrierten Informations- 


485 Vgl. Küster (2003), S. 10. 

486 Vgl. Hammerschall (2005), S. 118. 

487 Eine Übersicht zu einigen ausgewählten öffentlichen Verzeichnissen liefert z. B. 
KUSTER. Vgl. Küster (2003), S. 11. 


488 Vgl. Küster (2003), S. 10. 
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verarbeitung ließen sich in Abschnitt 3.1 zwei zentrale Problemfelder identifi- 
zieren, die eine integrierte Informationsverarbeitung gefährden. Während ein 
Problemfeld die hohen Kosten der Systementwicklung und Systemintegration 
thematisierte, hat ebenso das Problem einer mangelnden IT-Unterstützung der 
Geschäftsprozesse einer Unternehmung das Interesse am Konzept einer SOA in 
den vergangenen Jahren gefördert. 

Aufbauend auf den Ausführungen ausgewählter Literaturbeiträge, die in Ab- 
schnitt 3.2 in drei Auslegungsgruppen einer SOA unterteilt und diskutiert wur- 
den, fokussierte Abschnitt 3.3 die Softwareservices als konzeptionelles und 
technisches Fundament einer SOA. Dabei wurde in diesem Kapitel sowohl auf 
die Darstellung der Bestandteile eines Services als auch auf die Prinzipien Wert 
gelegt, die bei der Gestaltung von Services zu berücksichtigen sind. Die Frage 
nach einer geeigneten softwaretechnischen Implementierung einer SOA wurde 
in Abschnitt 3.4 erörtert, indem mit den Web Services eine von der SOA- 
Literatur favorisierte Technologie zur Realisierung einer SOA thematisiert wur- 
de. Zum Abschluss des vorliegenden Kapitels erfolgt in diesem Abschnitt die 
Präsentation eines integrierten Begriffsverständnisses einer SOA, das auf den 
Inhalten der Abschnitte 3.1 bis 3.4 basiert. 

In Abschnitt 3.2 wurde herausgestellt, dass sich SOA vor dem Hintergrund 
aktueller Literatur aus drei Blickwinkeln betrachten lässt. Hierbei stehen sich 
die Autoren, die den konzeptionellen Ansatz einer SOA favorisieren, denjeni- 
gen gegenüber, die die konkrete technische Implementierung einer SOA beto- 
nen.489 Der vorliegende Abschnitt verfolgt das Ziel, die verschiedenen Sicht- 
weisen zu einem integrierten SOA-Begriffsverständnis zusammenzuführen. Da- 
bei nehmen die folgenden Ausführungen zu der Frage Stellung, ob es sich bei 
SOA tatsächlich um ein neues Paradigma bzw. um einen Paradigmenwechsel in 
der Informationsverarbeitung handelt.49° Der Terminus des Paradigmenwech- 
sels folgt dabei der Begriffsauslegung von KUHN, der einen Paradigmenwechsel 
in allgemeiner Weise mit der Veränderung von Überzeugungen, Werten und 
Verfahrensweisen, die von den Mitgliedern einer bestimmten Gemeinschaft ver- 
treten werden, gleichsetzt.49! 

Mit Blick auf die in Abschnitt 3.3 präsentierten Auslegungen ist die Gemein- 
samkeit zu konstatieren, dass die Serviceorientierung einen fundamentalen Pfei- 
ler des SOA-Ansatzes darstellt. An dieser Stelle ist darauf hinzuweisen, dass die 
Idee, ein IS in Module bzw. Softwarebausteine zu zerlegen und diese in Form 
gekapselter Funktionen einer möglichst großen Nutzerzahl zur Verfügung zu 


489 Zur technisch-geprägten Auslegung einer SOA vgl. Abschnitt 3.2.2. Wie in Abschnitt 
3.2 deutlich wurde, vertreten die Repräsentanten der konzeptorientierten Auslegung ei- 
ner SOA die Auffassung, bei SOA handele es sich um ein Architekturkonzept (Ab- 
schnitt 3.2.1) und/oder um ein Rollenkonzept (Abschnitt 3.3.3). 

490 Siehe hierzu die Einführung des Abschnitts 3.2. 


491 Vgl. Kuhn (1976), S. 175. 
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stellen, kein Novum in der Informatik darstellt. Eine identische Zielsetzung 
wurde bereits in der Diskussion um die Entwicklung und den Einsatz kompo- 
nentenorientierter IS geaufert.492 Im Gegensatz zu einem monolithischen Sys- 
tem wird die Funktionalität in einem komponentenorientierten System von ver- 
schiedenen klar abgegrenzten Modulen bzw. Bausteinen erbracht, die eine Teil- 
funktionalität abbilden und zur Nutzung anbieten.493 Damit stellt der Einsatz ei- 
ner SOA im Vergleich zur Nutzung grob strukturierter Softwarepakete sowie 
monolithischer Applikationen die Möglichkeit in Aussicht, voneinander abge- 
grenzte Aufgaben in Form von Services anzubieten, die sich je nach Einsatz- 
zweck zu einem erweiterten Gesamtsystem frei kombinieren lassen.494 

Vor dem Hintergrund der in Abschnitt 3.1.1 vorgestellten Integrationstypen 
der Geräte-, Prozess-, Funktions-, und Datenintegration ist festzustellen, dass 
die Verwendung von Services gleichbedeutend mit der Existenz einer weiteren 
Integrationsschicht ist, die für eine integrierte Informationsverarbeitung zum 
Einsatz kommen kann. Mit Blick auf das Servicemodell in Abschnitt 3.3.1 lässt 
sich feststellen, dass eine oder mehrere Funktionen Bestandteil eines Services 
sein können. Services sollen wiederum als Aktivitäten zu einer Prozesskette zu- 
sammengesetzt und — so der Anspruch einer SOA - in verschiedenen Prozessen 
ausgeführt sowie von verschiedenen Servicenachfragern genutzt werden. Dies 
hat zur Folge, dass zwischen den Ebenen der Funktions- und Prozessintegration 
eine weitere eingefügt werden kann, die für die Integration von Softwareservi- 
ces steht. Eine vollständige Übersicht über alle Integrationsschichten einer SOA 
präsentiert Abbildung 21. 

Neben dem Servicebegriff liegt auch im Architekturterminus ein zentrales 
Charakteristikum einer SOA. Angelehnt an den Architekturbegriff nach 
FOEGEN/BATTENFELD,#95 steht SOA damit für die Regeln sowie Richtlinien, die 
bei der Entwicklung einer Serviceorientierten Anwendung zu berücksichtigen 
sind.496 Mit Blick auf das Architekturverständnis, das HERDEN ET AL. favorisie- 
ren, lässt sich SOA in gleicher Weise als ein Konzept auffassen, das zur Gestal- 
tung, Wartung, Dokumentation und Nutzung eines dienstorientierten IS ange- 
wendet werden kann.497 Dies hat zur Konsequenz, dass sowohl statische als 
auch dynamische Aspekte bei der Entwicklung und beim Betrieb einer SOA zu 


492 Diese Einschätzung teilen auch HOS ET AL., indem sie ausführen, dass sich die Grund- 
ideen einer SOA in der komponentenbasierten Softwareentwicklung wieder finden las- 
sen. Vgl. Höß et al. (2007), S. 40. 

493 Vgl. Hansen/Neumann (2005), S. 226. 

494 Vgl. Hansen/Neumann (2005), S. 532. Dieser Aspekt wird von LIEBHART plakativ als 
„Dienste statt Applikationen“ bezeichnet. Vgl. Liebhart (2007), S. 9. 

495 Vgl. Foegen/Battenfeld (2001), S. 291. 

496 Diese wurden als Designprinzipien in Abschnitt 3.3.2 thematisiert. 


497 Vgl. Herden et al. (2006), S. 1. 
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berücksichtigen sind.498 Mit Blick auf die statischen Eigenschaften einer SOA 
ist zu bemerken, dass einerseits die Designprinzipien die zentralen Richtlinien 
einer SOA darstellen. Die dynamische Perspektive zeichnet sich hingegen durch 
die Kommunikationsbeziehungen in einer SOA aus. 


Geräteintegration 


Prozessintegration 


Serviceintegration 


Funktionsintegration 


Datenintegration 


Abbildung 21: Erweiterung der Integrationstypen um die Ebene der Serviceintegration 


Wird Kommunikation als der Austausch von Nachrichten zwischen einem Sen- 
der und einem Empfänger verstanden,#9 liegt das Fundament für den Informa- 
tionsaustausch innerhalb einer SOA in der Existenz eines Serviceanbieters, ei- 
nes Servicenachfragers sowie eines Serviceverzeichnisses.500 Damit ein Nach- 
richtenaustausch zwischen den Servicenachfragern und -anbietern zustande 
kommt, ist die Voraussetzung zu erfüllen, dass ein Servicevertrag zur Verfü- 
gung gestellt wird, der in Form von Metadaten alle wesentlichen Informationen 
zum Aufruf eines Services enthält. 

Der Einsatz einer SOA bietet im Vergleich zu alternativen Konzepten punk- 
tuelle Erweiterungen, die eine Auseinandersetzung mit diesem Ansatz rechtfer- 
tigen. Diese Feststellung wird auch von TILKOV/STARKE gestützt, deren Auffas- 
sung zufolge die wichtigste Innovation einer SOA im Vergleich zu bereits be- 
währten Ideen, wie z.B. der Verwendung präziser Schnittstellen zur losen 
Kopplung von Softwaremodulen sowie der Einsatz von XML, in dem Einbezug 


498 Siehe hierzu die Ausführungen zum Architekturbegriff in Abschnitt 3.2.1. 
499 Vel. Gabriel/Beier (2003), S. 36. 
500 HERDEN ET AL. sprechen in diesem Zusammenhang von dem Grundmodell der SOA. 


Vgl. Herden et al. (2006), S. 6. 
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von Metadaten liegt. Diese ermöglichen neben der Beschreibung der funktiona- 
len Anforderungen insbesondere die präzise Definition nichtfunktionaler Eigen- 
schaften eines Services und deren Auswertung zur Laufzeit.50! Hierin liegt ein 
wichtiges Differenzierungsmerkmal einer SOA im Vergleich zu alternativen 
Ansätzen, die sich mit der Gestaltung integrierter IS auseinandersetzen. 

Darüber hinaus zeichnet sich das SOA-Konzept durch eine stärkere Berück- 
sichtigung des Internets aus, das die Rolle einer Kommunikationsplattform ein- 
nimmt, innerhalb dieser verteilte Dienste in Anspruch genommen werden kön- 
nen, die sich beispielsweise in Form von Web Services realisieren lassen.>02 Der 
Einsatz eines Netzwerks als Medium für den Aufruf der Web Services ermög- 
licht es, die Nutzung nicht nur auf diejenigen Dienste zu beschränken, die von 
einer Unternehmung implementiert und freigegeben wurden. Unternehmungen 
können ihre Services in gleichem Maße unternehmungsexternen Nutzern zur 
Verfügung stellen, wie sie die von unternehmungsexternen Anbietern bereitge- 
stellten Dienste nutzen können.503 

Durch den Einsatz standardisierter und offener Protokolle, wie es im Zusam- 
menhang mit dem Prinzip der „Verwendung technischer und offener Standards“ 
gefordert wird,504 soll die Möglichkeit eröffnet werden, eine Interaktion zwi- 
schen den heterogenen Anwendungssystemen einer Unternehmung herzustellen, 
die auf verschiedenen Programmiersprachen, Infrastrukturen oder Plattformen 
basieren.505 Gerade der Einsatz der Web Service-Technologie, die sich des 
XML-Standards bedient, ist eine wichtige Neuerung im Vergleich zu alternati- 
ven Integrationsansätzen.506 Dabei stellt die Nutzung der Web Service- 
Standards wie SOAP, WSDL und UDDI die Möglichkeit in Aussicht, nicht nur 
Dienste zu beschreiben, sondern auch ihre Auffindbarkeit und Komposition in- 
nerhalb einer SOA zu unterstiitzen.5°7 Wie bei der Vorstellung der Bausteine 
einer Web Serviceorientierten Anwendung deutlich wurde, fällt zur Implemen- 
tierung und Nutzung derartiger Services neben XML den Netzwerkprotokollen 
in ihrer Funktion als Transportprotokolle eine wichtige Bedeutung zu. 

Wie die Einschätzungen einiger Autoren belegen, wird die Implementierung 
und Nutzung einer SOA mit dem Einsatz von Web Services gleichgesetzt.5°8 An 
dieser Stelle ist darauf hinzuweisen, dass es sich hierbei ausschließlich um eine 
Empfehlung handeln darf. Keineswegs setzt der Betrieb einer SOA den Einsatz 


501 Vgl. Tilkov/Starke (2007), S. 36. 

502 Vgl. Beimborn/Weitzel (2003), S. 1360. 

503 Vgl. Hansen/Neumann (2005), S. 532. 

504 Vgl. Abschnitt 3.3.2.3. 

505 Vgl. Rieks (2006), S. 7. Siehe hierzu auch das Beispiel bei Küster (2003), S. 6. 

506 STREIBICH spricht in diesem Zusammenhang sogar von einer entscheidenden Neuerung. 
Vgl. Streibich (2008), S. 73. 

507 Vgl. Eymann/Winter (2008), S. 70. 


508 Vgl. hierzu Abschnitt 3.2.2. 
Alexander Pastwa - 978-3-631-75488-7 


Downloaded from PubFactory at 01/11/2019 04:20:29AM 
via free access 


102 Zusammenfassung und Ableitung eines integrierten SOA-Verständnisses 


von Web Services voraus.5°9 Auch wenn die Implementierung beim Software 
Engineering eine wichtige Phase darstellt, greift die Definition, die ausschließ- 
lich die technischen Aspekte bzw. den Einsatz einer bestimmten Technologie 
zur softwaretechnischen Umsetzung einer SOA fokussiert, zu kurz.5!0 Damit 
entfällt die Möglichkeit, eine SOA als bestimmte Technologie oder einen Tech- 
nologiestandard aufzufassen.>!! 

Mit Blick auf die fachlichen Anwendungsmöglichkeiten einer SOA ist fest- 
zuhalten, dass im Vergleich zu alternativen Integrationsansätzen der Fokus bei 
SOA auf die Geschäftsprozesse einer Unternehmung gelegt wird.5!2 Da die rei- 
ne IT-Sicht nicht im Vordergrund steht, lässt sich folglich eine integrierte Per- 
spektive sowohl auf die Geschäftsprozesse als auch auf die Anwendungssyste- 
me einer Unternehmung einnehmen .5!3 In diesem Zusammenhang verspricht der 
Einsatz einer SOA, die Geschäftsprozesse, die sowohl innerbetrieblich als auch 
unternehmungsübergreifend ausgeführt werden, durch den Einsatz geeigneter 
Services zu flexibilisieren und/oder zu automatisieren. Vor diesem Hintergrund 
bietet SOA das Potenzial, nicht nur technische sondern auch organisatorische 
Grenzen zu beseitigen.5!* Die Ausrichtung auf die Geschäftsprozesse einer Un- 
ternehmung, die sich mit Hilfe zusammengefügter Services automatisieren 
und/oder flexibilisieren lassen sollen, macht gleichzeitig deutlich, dass eine 
SOA immer eine unternehmungsspezifische Ausprägung aufweist. In Analogie 
zu alternativen Konzepten in der Wirtschaftsinformatik wie z.B. zum DWH- 
Konzept,>!5 das zur Gestaltung unternehmungsindividueller analyseorientierter 
IS genutzt wird, lässt sich eine SOA ebenfalls nicht als fertige Lösung von ei- 
nem Softwareanbieter erwerben und in einer Unternehmung einsetzen.3!6 


509 Alternativ lassen sich zur Implementierung einer SOA z. B. die Technologien Common 
Object Request Broker Architecture (CORBA), Distributed Component Object Model 
(DCOM) oder das Java-Pendant Remote Method Invocation (RMI) nutzen. Gemein ha- 
ben diese Ansätze, dass sie einen Zugriff auf entfernte Objekte ermöglichen. Die Grund- 
lagen zu diesen Technologien thematisiert z. B. HAMMERSCHALL. Vgl. Hammerschall 
(2005), S. 89ff., 127ff. und 190f. Zu den Einschränkungen dieser Lösungsvarianten vgl. 
Rieks (2006), S. 6. Dass sich eine SOA auf Basis von CORBA implementieren lässt, 
verdeutlicht das SOA-Projekt der Unternehmung CREDIT SUISSE. Vgl. Klostermeier 
(2008), S. 2. 

510 Die Auffassung, dass es sich bei einer SOA um ein technologieneutrales Konzept han- 
delt, wird auch von HOS ET AL. geteilt. Vgl. Höß et al. (2007), S. 40. 

SiI Vgl. hierzu auch Holtschke/Heier/Hummel (2009), S. 120; Thomas/Leyking/Dreifus 
(2007), S. 44; Reinheimer et al. (2007), S. 8. 

512 Vgl. Bauler et al. (2007), S. 57. 

513 Vgl. Tilkov/Starke (2007), S. 36. 

514 Vgl. Bauler et al. (2007), S. 57. 

515 Zum DWH-Konzept vgl. Gabriel/Röhrs (2003), S. 340ff.; Gluchowski/Gabriel/Dittmar 
(2007), S. 117 ff. 


516 Vgl. Streibich (2008), S. 73. 
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Da SOA als Ausprägung eines komponentenorientierten IS betrachtet werden 
kann und die Grundidee derartige Systeme keine Neuheit in der Informatik dar- 
stellt, ist im Ergebnis festzustellen, dass SOA, aus einer konzeptionellen Per- 
spektive betrachtet, keinen revolutionären Ansatz darstellt.5!7 Stattdessen han- 
delt es sich bei SOA um einen Ansatz, der die konsequente Fortführung etab- 
lierter Konzepte der Objekt- und Komponentenorientierung verfolgt,5!® um eine 
integrierte Informationsverarbeitung zu ermöglichen. Zu diesen gehören bei- 
spielsweise die Prinzipien der Abstraktion, Modularisierung, Standardisierung 
und Verteilung.5!9 Mit Blick auf die von KUHN formulierten Merkmale eines 
Paradigmenwechsels ist die Ansicht, bei SOA handele es sich um ein neues Pa- 
radigma in der Informatik, daher abzulehnen. 

Stattdessen wird in dieser Arbeit SOA als abstraktes Architekturkonzept auf- 
gefasst, bei dem wiederverwendbare und voneinander unabhängige Software- 
komponenten, die bestimmten Designprinzipien unterliegen und eine gezielte 
Funktion erfüllen, zur Unterstützung einer integrierten Informationsverarbei- 
tung zum Einsatz kommen. Auf fachlicher Seite richtet sich der Betrieb einer 
SOA auf das Ziel, innerbetriebliche und unternehmungsübergreifende Ge- 
schäftsprozesse durch den Einsatz zusammengefügter Services zu automatisie- 
ren und/oder zu flexibilisieren und auf diese Weise eine integrierte Informati- 
onsverarbeitung zu ermöglichen. Zur Implementierung der Services lassen sich 
diverse Technologien einsetzen, wobei insbesondere der Einsatz der Web Ser- 
vice-Technologie propagiert wird.520 


517 Vgl. Laartz (2008), S. 72. 

518 Vgl. Beverungen/Knackstedt/Müller (2008), S. 221. 

519 Diese Einschätzung wird auch plakativ in der Aussage von TERZIDIS/SURE/BRELAGE 
deutlich. Die Autoren bemerken: „SOA is nearly as old as computing itself from a tech- 
nical perspective“. Vgl. Terzidis/Sure/Brelage (2008), S. 76. 

520 Eine alternative, pragmatische Synthese ausgewählter Definitionsvorschläge zu SOA 


präsentieren Tilkov/Starke (2007), S. 17. 
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4 Architekturmodell für Serviceorientierte Berichtsprozesse 


In Kapitel 2 wurde herausgearbeitet, dass ein prozessorientiertes Berichtswesen 
auf eine integrierte Informationsverarbeitung angewiesen ist. Hierzu wurde in 
Kapitel 3 mit SOA ein aktuell diskutiertes Architekturkonzept vorgestellt, das 
sich losgelöst von einem bestimmten Anwendungsbereich insbesondere zur 
Flexibilisierung und/oder Automatisierung von Geschäftsprozessen und damit 
zur Gestaltung einer effizienten und effektiven Informationsverarbeitung ein- 
setzen lässt. Der in dieser Arbeit betrachtete Anwendungsbereich von SOA 
richtet sich auf die Informationsverarbeitung im betrieblichen Berichtswesen. 
Im Besonderen wird dabei der Frage nachgegangen, wie sich mit Hilfe dieses 
Konzepts Serviceorientierte Berichtsprozesse (SOBP) gestalten und eine unter- 
nehmungs- und/oder applikationsübergreifende Verarbeitung von Geschäfts- 
und Finanzinformationen auf Basis zusammengefügter Dienste implementieren 
lassen. >2! 

In diesem Zusammenhang ist nach THOME festzuhalten, dass sich die betrieb- 
liche Informationsverarbeitung sowohl durch den systematischen Aufbau ihrer 
Komponenten als auch durch die Abfolge der Schritte auszeichnet, die zur Ver- 
arbeitung der Daten und Informationen durchgeführt werden müssen, um ihre 
semantisch korrekte Aufbereitung und Darstellung zu erméglichen.522 Das die- 
ser Feststellung zugrunde liegende Erfordernis, die betriebliche Informations- 
verarbeitung anhand einer statischen und einer dynamischen Perspektive zu be- 
trachten, geht mit dem SOA-Verständnis der vorliegenden Arbeit einher. Vor 
dem Hintergrund der Tatsache, dass eine SOA die Zielstruktur einer IS- 
Architektur definiert und „Strukturen“ sowohl statische als auch dynamische 
Aspekte implizieren, widmet sich dieses Kapitel zunächst der statischen Per- 
spektive einer SOA. Entsprechend werden die grundlegenden Strukturen der 
Systemkomponenten einer SOA erörtert. 

Der Aufbau des vorliegenden Kapitels gestaltet sich wie folgt. In Abschnitt 
4.1 wird der Begriff „Serviceorientierter Berichtsprozess“ (SOBP) eingeführt. 
Um einen SOBP auf Basis einer SOA zu gestalten, ist es erforderlich, ein Archi- 
tekturmodell aufzustellen, das der Entwicklung und Realisierung einer derarti- 
gen Anwendung zugrunde liegt. Ein geeignetes Architekturmodell zur Gestal- 
tung von SOBP zu entwerfen, ist von großer Bedeutung, da ein SOBP einen für 
diese Arbeit zentralen Prozess darstellt, der sich auf Basis einer SOA automati- 
sieren und/oder flexibilisieren lässt. Vor diesem Hintergrund sind Überlegungen 
zum architektonischen Aufbau einer SOA grundsätzlicher Art und unabhängig 


521 Im Folgenden wird die Abkürzung „SOBP“ für Einzahl und Mehrzahl verwendet. 


522 Vgl. Thome (2007), S. 655. 
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von der zu unterstützenden prozessorientierten Anwendung. In Abschnitt 4.2 
wird hierzu das SOA-Ebenenmodell entwickelt, das sich zur Gestaltung und 
Ausführung Serviceorientierter Prozesse heranziehen lässt. 

Die Ausführungen des Abschnitts 4.3 widmen sich der Frage, welche Erwei- 
terungen am bestehenden SOA-Architekturmodell vorzunehmen sind, um die 
Informationsverarbeitungsprozesse im betrieblichen Berichtswesen durch den 
Einsatz einer SOBP zu verbessern. Als Erweiterung des Architekturmodells 
wird mit der Extensible Business Reporting Language (XBRL) ein Standard 
vorgestellt, der das Potenzial zur Gewährleistung der semantisch korrekten Ver- 
arbeitung von Geschäfts- und Finanzinformationen in einer SOA mit sich 
bringt. 

Das Kapitel schließt in Abschnitt 4.4 mit einer zusammenfassenden Würdi- 
gung des um XBRL erweiterten SOA-Architekturmodells. 


4.1 Begriff eines Serviceorientierten Berichtsprozesses 


Untersucht man vorhandene Publikationen zum Reporting und zu SOA, so ist 
festzustellen, dass eine einschlägige Definition des Begriffs „Serviceorientierter 
Berichtsprozess“ (SOBP) bislang fehlt. Vor diesem Hintergrund hat der vorlie- 
gende Abschnitt das Ziel, eine solche zu entwickeln. Das Verständnis für den 
Terminus eines SOBP basiert dabei auf den in den Abschnitten 2.2.2 und 3.3 
erarbeiteten Grundlagen der Berichtsprozesse und Softwaredienste. 

Unter einem SOBP wird in dieser Arbeit ein Berichtsprozess verstanden, bei 
dem die Aktivitäten und Teilprozesse der Kernprozesse Informationsbeschaf- 
fung und Berichtsproduktion, -verteilung sowie -aufnahme mit Hilfe von Servi- 
ces implementiert werden. Derartige Services werden im Folgenden als Be- 
richtsservices bzw. Berichtsdienste bezeichnet. Berichtsservices haben die Ver- 
arbeitung der im Rahmen eines Berichtsprozesses anfallenden Geschäfts- und 
Finanzinformationen zum Gegenstand. Sie sind nicht auf einen bestimmten 
Funktionsumfang beschränkt. Dies bedeutet, dass ein Berichtsservice sowohl 
lesende als auch schreibende Operationen durchführen kann, die bei einem oder 
mehreren Berichtsprozessen zum Einsatz kommen, wobei ein Berichtsservice 
im Hinblick auf seine Nutzungshäufigkeit flexibel ist. D. h., ein bestimmter Be- 
richtsservice lässt sich sowohl bei regelmäßig ausgeführten Berichtsprozessen 
als auch bei unregelmäßig stattfindenden Prozessen verwenden. 

Da es sich bei einem Berichtsservice um eine Ausprägung eines Services 
handelt, verfügen Berichtsdienste über alle in Abschnitt 3.3.1 präsentierten 
Merkmale sowie Bestandteile eines Services. Darüber hinaus folgen sie den in 
Abschnitt 3.3.2 thematisierten Prinzipien der Serviceorientierung. Die Einhal- 
tung der Prinzipien „lose Kopplung“, „Verwendung technischer und offener 
Standards“ und „Abstraktion von der Implementierungslogik“ hat zur Folge, 
dass sich die Berichtsservices als modulare Softwarekomponenten zu einem Be- 
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richtsprozess kombinieren und durch die Bereiststellung einer geeigneten IT- 
Infrastruktur ausführen lassen. Dabei setzen sie auf den bestehenden Daten der 
zum Einsatz kommenden Berichtssysteme und Datenformate auf.523 Die De- 
signprinzipien „lose Kopplung“ und „Abstraktion von der Implementierungslo- 
gik“ stellen in diesem Zusammenhang in Aussicht, dass sich Berichtsservices in 
einem oder in mehreren Kernprozessen des Berichtswesens einbinden lassen. 

Durch die Komposition von Berichtsservices wird zum einen die Verarbei- 
tung von berichteten Informationen entlang einer Berichtskette flexibilisiert 
und/oder automatisiert, zum anderen bietet der Einsatz von Berichtsservices, die 
auf Basis offener und technischer Standards implementiert wurden, das Poten- 
zial, Berichtsservices unternehmungsexterner Anbieter in einen bestehenden 
Berichtsprozess einzubinden. Als Beispiel für einen derartigen Service lässt 
sich ein Aktieninformationsdienst eines externen Anbieters anführen, der nach 
seinem Aufruf die Servicenutzer mit aktuellen Aktienkursen ausgewählter Un- 
ternehmungen versorgt.52* Durch die Integration unternehmungsexterner Be- 
richtsservices lassen sich Geschäfts- und Finanzinformationen anwendungs- 
und/oder unternehmungsübergreifend verarbeiten. 


4.2 SOA-Ebenenmodell als geeignetes Architekturkonzept für Serviceori- 
entierte Berichtsprozesse 


Damit sich Services in einer SOA aufrufen und zu einer dynamischen Prozess- 
kette kombinieren lassen, muss eine entsprechende Architektur bereitgestellt 
werden, mit der das Rollenkonzept einer SOA umgesetzt wird.525 Während die 
in Abschnitt 3.3.3 präsentierten Rollen und ihre Beziehungen die konzeptionelle 
Grundlage einer SOA darstellen, wird im Folgenden das architektonische Fun- 
dament einer SOA erarbeitet. 

Losgelöst von den verschiedenen kommerziellen sowie nicht kommerziellen 
Softwareprodukten, die aktuell zur Implementierung einer SOA angeboten wer- 
den, nehmen die Ausführungen dieses Abschnitts zu den Basisstrukturen einer 
SOA Stellung.526 In diesem Zusammenhang geht es um die Frage, welche zent- 
ralen Komponenten prägend für das Architekturverständnis einer SOA sind und 


523 Dabei lassen sich durch Berichtsservices sowohl operative bzw. disaggregierte als auch 
aggregierte Daten verarbeiten. 

524 Vgl. Bettag (2001), S. 302. 

525 Vgl. hierzu auch Beimborn/Mintert/Weitzel (2002), S. 277. 

526 Eine Zusammenstellung entsprechender nicht kommerzieller Produkte zur Implementie- 


rung einer SOA liefern Bauler et al. (2007), S. 58ff. 
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auf welche Weise sich diese Komponenten zu einer SOA-Referenzarchitektur 
bzw. zu einem SOA-Architekturmodell zusammenfiigen lassen.527 

Hinsichtlich der Zusammensetzung eines SOA-Architekturmodells zeichnen 
sich die in der Literatur präsentierten Vorschläge eher durch Gemeinsamkeiten 
als durch Unterschiede aus. Mehrheitlich stößt man dabei auf die Darstellung 
einer SOA-Referenzarchitektur als Ebenenmodell. Als Ergebnis einer Analyse 
ausgewählter Beiträge lässt sich ein Architekturmodell definieren, das aus vier 
Ebenen besteht.528 Dieses Modell setzt sich aus der Ebene der Anwendungssys- 
teme (Abschnitt 4.2.1), der Ebene der Services (Abschnitt 4.2.2), der Ebene der 
Prozesse (Abschnitt 4.2.3) und der Ebene der Frontendsysteme (Abschnitt 
4.2.4) zusammen. In den folgenden Abschnitten werden die Eigenschaften und 
Aufgaben der vier, übereinander angeordneten Ebenen des SOA-Architektur- 
modells sowie ihre Komponenten und Beziehungen konkretisiert. Dabei werden 
nicht nur technische, sondern auch fachliche Gesichtspunkte beleuchtet. Um die 
Ausführungen durchgängig übersichtlich zu halten, erfolgt eine systematische 
Erweiterung des Architekturmodells von der Ebene der Anwendungssysteme 
bis hin zur Ebene der Frontendsysteme. 

Die Ausprägung des Architekturmodells sowie die Bezeichnungen der ein- 
zelnen Komponenten sind dabei angelehnt an den Vorschlag von HEUTSCHI/ 
LEGNER/ÖSTERLE.529 Charakteristisch für das fokussierte Architekturmodell ist, 
dass es sich in eine anwendungsbezogene und eine anwendungsneutrale Sicht 
aufteilen lässt. Während bei der anwendungsbezogenen Sicht die Konzepte und 
Komponenten der jeweiligen Architekturebene eine auf den jeweiligen Einsatz- 
zweck ausgerichtete Ausprägung aufweisen — beispielsweise zur Unterstützung 
ausgewählter Geschäftsprozesse — zeichnen sich die Bausteine der anwen- 
dungsneutralen Perspektive durch einen allgemeingültigen Charakter aus. Sie 
lassen sich daher losgelöst von einem spezifischen Einsatzzweck betrachten. 


4.2.1 Ebene der Anwendungssysteme 


Auf der Ebene der Anwendungssysteme befinden sich alle betrieblichen Appli- 
kationen, welche die fachlichen Funktionen ebenso wie die Datenbestände zur 
Verfügung stellen, die Gegenstand der Serviceimplementierung sein können. 
Als zu nutzende Anwendungssysteme kommen beispielsweise Customer- 
Relationship-Management-Systeme (CRM-Systeme) und Supply-Chain- 


527 Die Begriffe Referenzarchitektur und Architekturmodell werden im Folgenden synonym 
verwendet. 

528 Vgl. hierzu die Vorschläge eines Architekturmodells von Erl (2005), S. 282; Heutschi/ 
Legner/Österle (2006), S. 362ff.; Liebhart (2007), S. 26ff.; Newcomer/Lomow (2005), 
S. 59; Josuttis (2008), S. 135ff. 


529 Vgl. Heutschi/Legner/Osterle (2006), S. 362ff. 
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Management-Systeme (SCM-Systeme) in Frage. Bei der Gestaltung eines SOBP 
ist vor allem die Anbindung von Enterprise-Resource-Planning-Systemen 
(ERP-Systemen) sowie allen weiteren Vorsystemen einer Berichtsanwendung 
von Bedeutung. Sie halten die Geschäfts- und Finanzinformationen vor, die zur 
Erfüllung der Berichtszwecke notwendig sind. Darüber hinaus kommen auch 
die in dem DWH einer Berichtsanwendung enthaltenen konsolidierten Daten — 
als Ergebnis einer multidimensionalen Aufbereitung der Daten aus den operati- 
ven Systemen — als Datenlieferanten in einer derartigen Serviceorientierten 
Anwendung in Betracht.530 Ziel ist es hierbei, sowohl unternehmungsinterne als 
auch unternehmungsexterne Anwendungssysteme im Rahmen einer SOA anzu- 
binden.53! Abbildung 22 verdeutlicht die Komponenten der Ebene der Anwen- 
dungssysteme innerhalb des SOA-Architekturmodells. 


Anwendungsbezogene Sicht | ‘Anwendungsneutrale Sicht: 
(fachliche Anwendungslogik) ' {Integrationsmechanismen) 


Anwendungs- : Applikations- ; REN AR, Applikations- 
rt bietet 
system | domäne iii Be = £ schnittstelle 


Abbildung 22: Ebene der Anwendungssysteme>32 


Wie in der Abbildung 22 zu erkennen ist, lassen sich auf der Ebene der Anwen- 
dungssysteme drei Architekturkomponenten unterscheiden. Im Mittelpunkt die- 
ser Ebene stehen die Applikationen, die im Rahmen einer SOA weiter betrieben 
werden sollen. Damit Services die Daten der Applikationen verarbeiten können, 
ist es erforderlich, dass die Anwendungssysteme eine entsprechende Schnittstel- 
le zur Verfügung stellen, die die Dienste nutzen können. Ferner lassen sich die 
einzelnen Anwendungssysteme zu Applikationsdomänen zusammenfassen. Ziel 
der Domänenbildung ist es, fachlich zusammengehörige Operationen bzw. 
Funktionen sowie Datenobjekte, die von den betriebenen IS zur Verfügung ge- 


530 Auf die Bedeutung von DWH-Systemen als Datenlieferanten in einer SOA verweisen 
z. B. DITTMAR und KRUCZYNSKI. Vgl. Dittmar (2007), S. 135ff.; Kruczynski (2006), S. 
25. 

531 Vgl. Heutschi/Legner/Österle (2006), S. 363. 

532 In Anlehnung an Heutschi/Legner/Osterle (2006), S. 364. Im Vergleich zum Vorschlag 
von HEUTSCHI/LEGNER/ÖSTERLE wird die Komponente der Applikationsdomäne in die- 
ser Arbeit als Bestandteil der Ebene der Anwendungssysteme betrachtet, da der Fokus 
dieser Komponente gerade darin liegt, die Funktionalitäten der betriebenen Anwen- 


dungssysteme nach fachlichen Gesichtspunkten zu Domänen zu strukturieren. 
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stellt werden und sich für eine Serviceimplementierung eignen, redundanzfrei 
zu gruppieren.>33 

Nach der Analyse der Schnittstellen sind in einem nächsten Schritt sämtliche 
Operationen bzw. Funktionen zu identifizieren, die von den betriebenen IS zur 
Verfügung gestellt werden. 

Während in dem hier präsentierten Architekturmodell die Anwendungssys- 
teme das Fundament einer SOA darstellen, schlägt LIEBHART vor, mit der 
Schicht der Virtualized Infrastructure eine weitere Ebene zu betrachten.534 Die- 
se ist unterhalb der Ebene der Anwendungssysteme positioniert. Auf ihr sind al- 
le technischen sowie infrastrukturellen Ressourcen zum Betrieb sämtlicher 
SOA-Komponenten (wie Prozessoren, Arbeitsspeicher, Netzwerkverbindungen, 
etc.) bereitzustellen und zu steuern.535 Dieser Sichtweise zufolge repräsentiert 
die Ebene der Anwendungssysteme die Datensicht sowie die fachliche Ressour- 
censicht innerhalb des SOA-Architekturmodells, während die darunter liegende 
Schicht der Virtualized Infrastructure auf eine technische Ressourcensicht ab- 
zielt. Da die technischen Ressourcen einen integralen Bestandteil von Anwen- 
dungssystemen darstellen, wird die von LIEBHART vorgenommene Separierung 
in zwei Ebenen in der vorliegenden Arbeit nicht weiter verfolgt. 


4.2.2 Ebene der Services 


Oberhalb der Ebene der Anwendungssysteme befindet sich die Ebene der Servi- 
ces. Auf der Serviceebene werden alle Dienste betrachtet, die der SOA- 
betreibenden Unternehmung entweder infolge einer externen Bereitstellung 
oder durch Eigenentwicklung zu einem gegebenen Zeitpunkt zur Verfügung 
stehen. Als Ausgangspunkt dient das Servicemodell, das in Abschnitt 3.3.1 er- 
örtert wurde. Damit sich die Funktionalitäten von Services voneinander ab- 
gegrenzen lassen, wird in Abschnitt 4.2.2.1 eine gebräuchliche Kategorisierung 
von Diensten vorgestellt. Die Servicearten werden daraufhin als logische Kom- 
ponente in das Architekturmodell aufgenommen. Als weitere Komponente der 
Ebene der Services werden in Abschnitt 4.2.2.2 die Middlewaredienste themati- 
siert. Im Anschluss erfolgt in Abschnitt 4.2.2.3 die Einbindung der zuvor be- 
trachteten Komponenten in die Ebene der Services. 


533 Siehe hierzu die Ausführungen in Abschnitt 5.2.2.3. 
534 Vgl. Liebhart (2007), S. 27. 


535 Vgl. Liebhart (2007), S. 27. 
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4.2.2.1 Servicekategorien 


Eine Klassifizierung von Servicetypen lässt sich anhand der Kategorien Daten- 
services, Funktionsservices und Prozessservices durchführen.536 Datenservices 
haben die Aufgabe, die Daten der IS, auf die die Dienste zugreifen, zu verarbei- 
ten. Im Fokus können sowohl Stammdaten als auch Prozessdaten stehen.°3’ Als 
alternative Bezeichnungen für Datenservices werden in der Literatur die Termi- 
ni Bestandsservices, Basisservices oder datenzentrierte Services verwendet.538 
Ihr Leistungsumfang umfasst die so genannten CRUD-Operationen.°39 Das Ak- 
ronym CRUD steht dabei für die Operationen Create, Read, Update und Dele- 
te.540 Aus der Wortwahl ist ersichtlich, dass die Datenoperationen an den Be- 
fehlsumfang von Datenbanksprachen, wie z. B. der Structured Query Language 
(SQL), angelehnt sind. Von Bedeutung sind in diesem Zusammenhang die 
Sprachelemente bzw. Befehle der Data-Manipulation-Language (DML) von 
SQL.54! 


536 Diese Klassifizierung verwenden auch Luhmann/Meister/Wulff (2007), S. 345. Neben 
den Daten-, Funktions- und Prozessservices werden so genannte Interaktionsservices als 
weitere Dienstkategorie genannt. Vgl. Lauer/Juwig (2007), S. 267. In dieser Arbeit wird 
die Auffassung vertreten, dass sich Interaktionsservices nicht als Servicekategorie ver- 
stehen lassen, da sie nicht dem Servicebegriff entsprechen, der einer SOA zugrunde 
liegt. Vgl. hierzu auch Hess/Humm/Voß (2006), S. 399. Interaktionsservices ermögli- 
chen den verschiedenen Nutzern einer SOA einen Zugriff auf die Dienste. Die Anwen- 
der können in diesem Zusammenhang verschiedene Medien bzw. Kanäle in Anspruch 
nehmen, zu denen beispielsweise Intranet- sowie Internet-Portale gehören. Die Interak- 
tionsservices sind daher gesondert von den vorherigen drei Servicekategorien zu be- 
trachten, da ihre Services keine Schnittstellen im softwaretechnischen Sinne darstellen. 
Vielmehr stehen sie für die verschiedenen Benutzungsschnittstellen bzw. Zugriffskom- 
ponenten, die einem Anwender zur Inanspruchnahme eines Daten-, Funktions- und Pro- 
zessservice zur Verfügung stehen. 

537 Vgl. Krafzig/Banke/Slama (2007), S. 88; Lauer/Juwig (2007), S. 266. 

538 Da ,,Basisservices“ auch als übergeordneter Terminus für alle elementaren Operationen 
verwendet wird und damit sowohl die Daten- als auch die Funktionsservices einschließt, 
lassen sich die Datenservices auch als Basisservices i. e. S. verstehen. Vgl. Höß et al. 
(2007), S. 40. Um eine eindeutige begriffliche Zuordnung zu gewährleisten, werden in 
dieser Arbeit die Basisservices auch als Datenservices bezeichnet, von den Funktions- 
services abgegrenzt und als eigene Servicekategorie betrachtet. 

539 Vgl. Hess/Humm/Voß (2006), S. 399. 

540 Zu den CRUD-Operationen vgl. Keller (2007), S. 362. 

541 Zur Einführung in die DML-Funktionen von SQL vgl. z. B. Gabriel/Röhrs (2003), S. 


64ff.; Pernul/Unland (2003), S. 403ff. 
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Mit Hilfe der Bestandsservices lassen sich neue Datensätze anlegen (Create) 
sowie bestehende Datensätze auslesen (Read).542 Darüber hinaus können beste- 
hende Datensätze aktualisiert (Update) und gelöscht (Delete) werden. Festzu- 
halten ist, dass es sich bei diesen vier Operationen um elementare Operationen 
handelt.5# Sie dienen der Erzeugung von Datensichten sowie der Durchführung 
von Datenpflegeoperationen, wobei Konsistenzbedingungen einzuhalten bzw. 
zu überwachen sind.5* Darüber hinaus zeichnen sich Bestandsservices durch 
einen hohen Grad an Eigenständigkeit bzw. Unabhängigkeit aus.545 Beispiele 
für Bestandsservices sind die Buchung eines Umsatzbetrags oder die Historisie- 
rung von Daten. 

Funktionsservices zielen darauf ab, die verschiedenen Geschäftsfunktionen 
einer Unternehmung softwaretechnisch abzubilden.5 In Anlehnung an 
KRAFZIG/BANKE/SLAMA lassen sich Funktionsservices auch als logikzentrierte 
Services bezeichnen. Derartige Service zeichnen sich durch die Kapselung von 
Verarbeitungsanweisungen aus, die sich sowohl für einfache und komplexe Be- 
rechnungen als auch für Geschäftsregeln einsetzen lassen. Funktionsservices 
können auf den Bestandsdiensten aufsetzen, indem sie diese zur Datenlieferung 
sowie — nach erfolgter Verarbeitung der Dateneingabe — zur Datenrückschrei- 
bung nutzen.°47 Auch lassen sie sich als atomare Dienste aufrufen, die unab- 
hängig von anderen Services verwendet werden und die erforderlichen lesenden 
und schreibenden Operationen selbständig ausführen. Ein Beispiel einer auf Ba- 
sis eines Funktionsservices zu unterstützenden Geschäftsfunktion ist die Boni- 
tätsprüfung eines Kunden oder die Erstellung von Abrechnungen.548 

Prozessservices, die auch als prozesszentrierte Services, Business-Services 
und als Geschäftslogik-Services bezeichnet werden,549 sind darauf ausgerichtet, 
die einzelnen Funktions- und Bestandsservices zu koordinieren und zu einem 
übergeordneten Service zusammenzuftigen.*>° Mit Hilfe von Prozessservices 


542 Kame ein relationales Datenbanksystem zur Durchführung der CRUD-Operationen zum 
Einsatz, ist an dieser Stelle darauf hinzuweisen, dass die Create-Operation, d. h. das An- 
legen von Datensätzen, dem „Insert Into“-Befehl aus dem DML-Befehlssatz von SQL 
entspricht und nicht mit dem „Create Table“-Befehl aus dem DDL-Befehlssatz von SQL 
verwechselt werden sollte. Die übrigen Operationen, d. h. die RUD-Operationen, lassen 
sich mit Hilfe des Select-, Update- und Delete-Befehls von SQL implementieren. 

543 Vgl. Höß et al. (2007), S. 40. 

544 Vgl. Hess/Humm/Voß (2006), S. 399. 

545 Vgl. von Henning (2007), S. 351 und 353. 

546 Vgl. Hess/Humm/VoB (2006), S. 399. 

547 Vgl. Lauer/Juwig (2007), S. 266. 

548 Vgl. Hess/Humm/Voß (2006), S. 399. 

549 Vgl. Höß et al. (2007), S. 40; Luhmann/Meister/Wulff (2007), S. 345. 

550 Vgl. Lauer/Juwig (2007), S. 267; von Henning (2007), S. 351; Hess/Humm/Voß (2006), 


S. 399, 
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lassen sich Geschäftsprozessmodule ausführen.55! Darüber hinaus können Pro- 
zessservices wiederum als Teilprozesse in einen übergeordneten Prozessservice 
eingebunden werden. 

Im Vergleich zu den Basis- und den Funktionsservices zeichnen sich Pro- 
zessservices auf der einen Seite dadurch aus, dass sie statusbehaftet sind, da sie 
ihren Status für die sie aufrufende Instanz jeweils selbst kontrollieren und ver- 
walten.552 Auf der anderen Seite weisen prozesszentrierte Services im Vergleich 
zu den Basis- und Funktionsservices einen stärkeren Prozessbezug bzw. eine 
höhere Prozessspezifität auf, da sie sich aus verschiedenen Daten- und Funkti- 
onsservices zusammensetzen, die zur Ausführung einer bestimmten Aktivität 
oder eines Teilprozesses verknüpft wurden. 


4.2.2.2 Middlewaredienste 


Innerhalb der Ebene der Services erfüllen die Middlewaredienste eine wichtige 
Funktion. Ihnen obliegt die Aufgabe der Daten-, Funktions- und Präsentations- 
integration, womit Middlewaredienste als Integrationskomponente des Archi- 
tekturmodells zu verstehen sind. Sie sind für die Verknüpfung der verschiede- 
nen Dienste zuständig und ermöglichen die Kopplung zwischen den Diensten 
und den Anwendungen über die entsprechenden Schnittstellen. Der dritte Auf- 
gabenbereich richtet sich auf die Verbindung der Services mit den zum Einsatz 
kommenden Frontendsystemen.553 Mit Blick auf die technische Ausprägung der 
Middlewaredienste kommt zur Erfüllung aller drei Aufgabenbereiche typi- 
scherweise ein Enterprise-Service-Bus (ESB) zum Einsatz. 

Ein ESB enthält Instrumente zur sicheren und garantierten Meldungsübertra- 
gung, zum Logging und zur Autorisierung. Routingmechanismen sowie Mana- 
gement- und Überwachungstools werden ebenfalls von einem ESB bereitge- 
stellt.554 Ein ESB übernimmt die Details der Kommunikation, die erforderlich 
sind, damit Servicenehmer mit Serviceanbietern in Kontakt treten kénnen.555 
Eine wichtige Funktion ist in diesem Zusammenhang die Uberwindung hetero- 
gener Technologien, da i. d. R. ein Servicenutzer in einer anderen Programmier- 
sprache implementiert ist als der Serviceprovider. Darüber hinaus sorgt ein ESB 
für die technische Konnektivität zwischen allen Komponenten einer SOA. Dies 
betrifft auch die notwendigen Netzwerk- und Protokolldetails.556 


551 Vgl. Roth (2007), S. 99. 

552 Vgl. Krafzig/Banke/Slama (2007), S. 96. 

553 Vgl. Abschnitt 4.2.4. 

554 Vgl. Liebhart (2007), S. 136; Tilkov/Starke (2007), S. 34. 

555 Vgl. Tilkov/Starke (2007), S. 34; Buxmann/Hess/Widjaja (2007), S. 1320. 


556 Vgl. Tilkov/Starke (2007), S. 34. 
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4.2.2.3 Beziehungen zwischen den Komponenten der Serviceebene 


Abbildung 23 verdeutlicht, wie sich das in Abschnitt 3.3.1 diskutierte Service- 
modell, die Servicekategorien (Abschnitt 4.2.2.1) sowie die Middlewaredienste 
(Abschnitt 4.2.2.2) in die Ebene der Services einbinden lassen. 


Anwendungsbezogene Sicht | ‘Anwendungsneutrale Sicht: 
(fachliche Anwendungslogik) (Integrationsmechanismen) 


beschreibt enthalt 
Services | Service- u 
spezifikation 


Middleware- 
dienste 


Anwendungs- Applikations- 
systeme schnittstelle 


Abbildung 23: Erweiterung des SOA-Architekturmodells um die Ebene der Services 


Zur Nutzung der Dienste ist innerhalb der Serviceebene eine Komponente ein- 
zubinden, die es ermöglicht, die aktuell zur Verfügung stehenden Dienste zu re- 
gistrieren, zu verwalten und aufzufinden. Diese Funktionalität wird von einem 
Serviceverzeichnis übernommen.557 Das Serviceverzeichnis enthält die Service- 
beschreibungen, die zum Auffinden der Dienste zur Laufzeit herangezogen 
werden.°58 Darüber hinaus verweist das Serviceverzeichnis auf die Service- 
schnittstellen. Wie in der Abbildung 23 dargestellt, setzen die Serviceschnitt- 
stellen auf Schnittstellen der Anwendungssysteme auf, um ihre spezifischen 
Funktionalitäten zu erbringen. Vor dem Hintergrund ihrer Bedeutung für die 


557 Zu alternativen Bezeichnungen sowie zu den Aufgaben eines Serviceverzeichnisses in- 
nerhalb des SOA-Rollenkonzepts vgl. Abschnitt 3.3.3. CONRAD ET AL. empfehlen in 
diesem Zusammenhang die Service-Registry von dem Service-Repository, das zur Un- 
terstützung des Entwicklungsprozesses zum Einsatz kommt, zu unterscheiden. Vgl. 
hierzu Conrad et al. (2006), S. 90. 


558 Vgl. Conrad et al. (2006), S. 90. 
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konzeptionelle Gestaltung Serviceorientierter Prozesse wird in Erweiterung des 
in Abschnitt 3.3.1 diskutierten Servicemodells die Servicekategorie als logische 
Komponente ins Architekturmodell aufgenommen.559 Die Verbindung zwischen 
den Komponenten „Applikationsdomäne“ und „Services“ weist ebenfalls auf 
eine logische Beziehung hin, die zur Aussage hat, dass sich aus den gruppierten 
Funktionen und Datenobjekten einer Applikationsdomäne Services identifizie- 
ren und kapseln lassen. Mit Blick auf die Komponenten, die sich auf der Ebene 
der Services befinden, lässt sich diese folglich als organisationsweite und stan- 
dardisierte Schnittstellen- und Kommunikationsschicht auffassen. 


4.2.3 Ebene der Prozesse 


Als weitere Schicht in dem SOA-Architekturmodell ist die Ebene der Prozesse 
eingebunden. Der Gegenstandsbereich dieser Schicht liegt darin, Services zu 
einem Gesamtprozess mit dem Ziel zu verknüpfen, die im Rahmen einer SOA 
angestrebte Automatisierung und/oder Flexibilisierung von Prozessen über Sys- 
temgrenzen hinaus zu erreichen.56° Zur Erfüllung dieses Ziels kommen 
Workflow Management-Systeme (WMS) zum Einsatz, deren Aufbau und 
grundsätzliche Funktionalität in Abschnitt 4.2.3.1 erläutert werden. Abschnitt 
4.2.3.2 widmet sich den Kopplungsmechanismen, die bei der Verknüpfung von 
Services von Bedeutung sind. In Abschnitt 4.2.3.3 werden die Beziehungen 
zwischen den Komponenten der Ebene der Services erörtert. 


4.2.3.1 Worflow Management-Systeme 


Allgemein werden WMS genutzt, um Personen bei der Durchführung der Ge- 
schäftsprozesse zu unterstützen und den Ablauf der einzelnen Teilprozesse zu 
automatisieren.56! WMS werden mit dem Ziel betrieben, die Qualität der Ge- 
schäftsprozesse hinsichtlich der Integration von Prozessschritten und Informati- 
onsflüssen zu verbessern.562 

Mit Blick auf den Einsatzzweck von WMS im Rahmen einer SOA besitzt 
diese Systemkategorie die Aufgabe, den Ablauf eines rollen- sowie applikati- 
onsübergreifenden Geschäftsprozesses durch den dynamischen Aufruf entspre- 


559 Siehe hierzu Abschnitt 5.2.3.2. 

560 Die Existenz einer Ablaufsteuerung ist nicht nur zur Ausführung von Berichtsprozessen 
erforderlich, sondern betrifft alle Unternehmungsprozesse, die eine abteilungsübergrei- 
fende Koordination erfordern. Zu diesen gehören beispielsweise der Balanced- 
Scorecard-Prozess sowie der Budgetierungsprozess. Vgl. Oehler (2006), S. 103. 

561 Vgl. Deppisch/Oppitz (2004), S. 886. 


562 Vel. Deppisch/Oppitz (2004 , S. 887. 
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chender Dienste zu steuern.563 Dafür ist es notwendig, dass die gesamte Ablauf- 
logik in einem ausführbaren Prozessmodell vorliegt. Ein Workflow lässt sich in 
diesem Zusammenhang als (Teil-)Prozess auffassen, der zur Ausführungszeit 
automatisiert durchlaufen werden kann. Jeder Service steht dabei für eine Pro- 
zessaktivität, was impliziert, dass jede Prozessaktivität aus untergeordneten Ak- 
tivitäten bestehen kann. 


Process 
Definition 
Tools 


Interface 1 


Interface 4 


Interface 5 Workflow 
Enactment 


Service Other Workflow 
Enactment 
Services 


Administration 
and Monitoring Workflow 
Tools Engine Workflow i 


Engine 


Interface 2 Interface 3 
Workflow Client Invoked 
Applications Applications 


Abbildung 24: Bestandteile eines WMS564 


Vor dem Hintergrund der Bedeutung von WMS für die Implementierung einer 
SOA werden im Folgenden die in Abbildung 24 illustrierten charakteristischen 


563 Vgl. Hansen/Neumann (2005), S. 447. Diese Funktionalität wird in der von BERBNER ET 
AL. präsentierten Architektur einer Serviceorientierten Anwendung von einer Proxy- 
Komponente übernommen. Vgl. Berbner et al. (2005), S. 273f. 


564 In Anlehnung an Liebhart (2007), S. 89. 
Alexander Pastwa - 978-3-631-75488-7 


Downloaded from PubFactory at 01/11/2019 04:20:29AM 
via free access 


Architekturmodell für Serviceorientierte Berichtsprozesse 117 


Komponenten eines derartigen Systems vertieft. Die Vorstellung der Kompo- 
nenten orientiert sich an dem Referenzmodell für WMS, das von der Workflow 
Management Coalition (WfMC) entwickelt wurde.565 

Der Workflow Enactment Service (WES) stellt die zentrale Komponente eines 
WMS dar. Sie setzt sich aus den Workflow-Engines zusammen, deren Aufgabe 
es ist, die Workflows zu steuern, den Benutzern die durchzuführenden Aktivitä- 
ten zuzuordnen sowie externe Programme einzubinden. Ferner übernimmt der 
WES die Benutzerverwaltung. Weitere Aufgaben des WES umfassen die ter- 
mingerechte Weiterleitung von Meldungen an andere Workflow-Systeme. 

Als Process Definition Tools werden alle Werkzeuge bezeichnet, die zur 
Analyse, Modellierung, Beschreibung und Dokumentation der Geschäftsprozes- 
se zum Einsatz kommen. Diese Werkzeuge lassen sich in ein WMS integrieren 
oder als eigenständige Tools betreiben. In zuletzt genanntem Fall erfolgt die 
Kommunikation mit dem WES über das Interface 1. 

Als weitere Komponente sind die Workflow Client Applications (Interface 2) 
von Bedeutung. Workflow Client Applications lassen sich als Nachrichtendienst 
auffassen. Arbeitsschritte, die noch zur Bearbeitung anstehen, werden mit Hilfe 
der Workflow Client Applications in einer so genannten Worklist gespeichert. In 
ihr werden alle auszuführenden Arbeitsschritte eines Geschäftsprozesses und 
die an der Durchführung beteiligten Mitarbeiter dokumentiert. Nachdem die Tä- 
tigkeiten durch die Nutzer der Workflow Client Application abgearbeitet wur- 
den, leitet diese die Ergebnisse an den WES weiter. 

Invoked Applications als weitere Komponente eines WMS lassen sich über 
das Interface 3 an den WES anbinden. Hierbei handelt es sich um externe, ei- 
genständige Applikationen wie Office-Tools und Datenbankanwendungen, die 
sich ohne eine Benutzerinteraktion aufrufen lassen, um die Abwicklung eines 
Arbeitsschrittes zu unterstützen. Die Anwendungen können auf verschiedenen 
Plattformen betrieben werden. 

Das Interface 4 hat die Aufgabe, die Interoperabilität unterschiedlicher In- 
formationen und Vorgangssteuerungen zwischen verschiedenen WMS zu ge- 
währleisten. Mit Hilfe der Other Workflow Enactment Services lassen sich auf 
diese Weise laufende Prozesse synchronisieren. Ebenso können mit Hilfe dieser 
Komponente Prozesse verteilt auf mehreren Workflow-Servern ausgeführt wer- 
den. 

Das Interface 5 dient zur Standardisierung und Verbindung der Administrati- 
on and Monitoring Tools mit der Workflow-Engine. Mit Hilfe dieser Anwen- 
dungen lässt sich die Vorgangssteuerung unterstützen. Darüber hinaus stellen 
sie Informationen über den Ausführungsstatus und den Fortschritt einzelner 
Prozesse sowie den Zustand und die Auslastung der zugehörigen Instanzen zur 
Verfügung. Diese Informationen sind erforderlich, um die Kontrolldaten statis- 


565 Vgl. Workflow Management Coalition (2009). 
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tisch auswerten und Verbesserungsmöglichkeiten des Systems ableiten zu kön- 
nen. 


4.2.3.2 Kopplungsmechanismen zwischen Services 


Um die Ausführung applikations- und/oder unternehmungsübergreifender Ge- 
schäftsprozesse mit Hilfe von Services zu ermöglichen, ist es bedeutsam, die 
zum Einsatz kommenden Dienste zweckorientiert zu verbinden bzw. zu kompo- 
nieren. Dabei wird mit dem Einsatz einer SOA das Ziel verfolgt, einzelne Servi- 
ces zu übergeordneten Diensten zu verkniipfen.5® Die übergeordneten Dienste 
wiederum lassen sich als Aktivitäten eines Serviceorientierten Geschäftsprozes- 
ses nutzen, wobei zur Service-Komposition zwei Ansätze denkbar sind: Die 
Dienste können orchestriert oder choreografiert werden.567 Da im SOA-Umfeld 
in den meisten Fällen Web Services zum Einsatz kommen, orientieren sich die 
nachstehenden Ausführungen zu den beiden Ansätzen an dieser Technologie. 

Die Orchestrierung bzw. Orchestration zeichnet sich dadurch aus, dass ein 
Web Service genutzt wird, um einen vollständigen Geschäftsprozess, der wie- 
derum aus orchestrierten Services besteht, zu steuern.?68 Der betreffende Web 
Service lässt sich mit Hilfe einer WSDL spezifizieren sowie unter Einsatz von 
SOAP aufrufen. Charakteristisch für eine Orchestrierung ist, dass eine ausführ- 
bare Geschäftslogik vorliegt, welche die Reihenfolge und alle Bedingungen zur 
Ausführung der verknüpften Services enthält. Für diesen Zweck muss eine Pro- 
zessbeschreibung erstellt und im Laufzeitsystem hinterlegt werden. Die Pro- 
zessbeschreibung enthält sämtliche Steuerungsinformationen, mit denen ein 
Service weitere Dienste aufruft, diese mit Daten versorgt und die Ergebnisse 
empfängt. Zur Koordination der Interaktionen der beteiligten Services kommt 
eine zentrale Steuerungseinheit zur Anwendung. Services, die, wie im linken 
und rechten Kasten der Abbildung 25 dargestellt, in einer bestimmten Ablauf- 
reihenfolge festgelegt und für diesen Zweck parametrisiert sind, werden als or- 
chestriert bezeichnet.>569 

Charakteristisch für die Choreografie (Choreography) ist, dass kollaborative 
Geschäftsprozesse anhand der Interaktionen zwischen den verknüpften Services 
sowie der dadurch entstehenden Abhängigkeiten beschrieben werden. Im Ge- 
gensatz zur Orchestrierung von Services wird bei der Choreografie keine aus- 
führbare Prozessdefinition vorgehalten. Lediglich die Interaktionen zwischen 


566 Vgl. Winkler (2007), S. 258. 

567 Vgl. vom Brocke (2007), S. 27f. 

568 Der Bezeichnung „Orchestrierung“ liegt die Vorstellung zugrunde, dass der zentrale 
Service Aufgaben übernimmt, die sich mit den Aufgaben eines Orchesterdirigenten ver- 
gleichen lassen. Vgl. vom Brocke (2007), S. 27. 


569 Vgl. Buxmann/Hess/Widjaja (2007), S. 1317. 
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den Services an den betreffenden Schnittstellen werden definiert. Folglich ist 
bei der Choreografie ausschließlich das „von außen“ sichtbare Verhalten der 
Services von Bedeutung. Eine zentrale Steuerungseinheit (wie bei der Orchest- 
rierung) liegt bei der Choreografie nicht vor, so dass sich die choreografierten 
Services entsprechend der Prozessstruktur sequentiell selbst aufrufen. Für die- 
sen Zweck müssen alle Steuerungs- und Nutzdaten zwischen den Services aus- 
getauscht werden. Nachdem der Auslöser der choreografierten Prozesskette den 
ersten Dienst ausführt, wird das Ergebnis des letzten Dienstes an den Auslöser 
übermittelt. 


Choreografie 
Orchestrierung Orchestrierung 


Request (1) 


Response (2) 


Request (3) 


Abbildung 25: Zusammenhang zwischen Serviceorchestrierung und -choreografie 


In der Abbildung 25 wird der Zusammenhang zwischen der Orchestrierung und 
der Choreografie von Services dargestellt. Festzuhalten ist, dass sich beide 
Ausprägungen zur Verknüpfung von Services in einer kombinierten Weise nut- 
zen lassen. Während die Orchestrierung zur Steuerung innerbetrieblicher Pro- 
zesse verwendet werden kann, bietet die Choreografie Vorteile bei der zwi- 
schenbetrieblichen Ausführung von Geschäftsprozessen.5’0 Wie in der 
Abbildung 25 deutlich wird, lassen sich mit Hilfe der Choreografie verschiede- 
ne Orchestrierungen verbinden. In dem zugrunde liegenden Beispiel erfolgt 
nach einer Request-Nachricht (1 und 3) eine entsprechende Response-Nachricht 
(2 und 4). 


570 Vgl. vom Brocke (2007), S. 28. 
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Zur Beschreibung und Automatisierung von Services werden aktuell insbe- 
sondere der BPEL-Standard und seine Nachfolger diskutiert.5”! BPEL ist eine 
auf XML basierende Sprache zur Entwicklung von Geschäftsprozessen, die auf 
Basis von Web Services implementiert werden, und hat sich in diesem Bereich 
als De-facto-Standard etabliert.572 

Ein BPEL-Prozess umfasst die zeitliche und logische Abfolge von verschie- 
denen Web Service-Aufrufen und repräsentiert damit das informationstechni- 
sche Gegenstück zum fachlichen Prozessmodell.573 Mit IT-gestützten BPEL- 
Werkzeugen lässt sich der generierte BPEL-Prozess simulieren und die Zusam- 
menstellung der prozesszugehörigen Services prüfen. Dadurch kann BPEL auch 
zur Qualitätssicherung bzw. -kontrolle einer SOA eingesetzt werden.574 Zudem 
lässt sich eine BPEL-Beschreibung digital archivieren und zu einem späteren 
Zeitpunkt wieder verwenden. Dadurch wird erreicht, dass die orchestrierten 
Services nicht erneut beschrieben werden müssen.5’5 Entsprechende Ressourcen 
können eingespart und für andere Aktivitäten eingesetzt werden. 

Der Einsatz von BPEL zur Implementierung eines SOBP ist zu befürworten, 
da sich dieser Standard sowohl zur Orchestrierung als auch zur Choreografie 
von Web Services nutzen lässt. Demnach ist es möglich, diesen Standard zur 
Realisierung sowohl eines unternehmungsinternen als auch -übergreifenden Be- 
richtsprozesses zu nutzen. 


4.2.3.3 Beziehungen zwischen den Komponenten der Prozessebene 


Wie Abbildung 26 zeigt, befindet sich die Ebene der Prozesse über der Ebene 
der Services. Die Ausführung der Prozessaktivitäten und damit der Services er- 
folgt anhand der Workflows, die mit Hilfe eines WMS implementiert und ge- 
steuert werden. Damit sich die Services aufrufen lassen, muss das eingesetzte 


571 Vgl. Modjo Kamneng (2007), S. 290. Bisher ist den verschiedenen Standardisierungs- 
initiativen nicht gelungen, einen einheitlichen Standard zur Orchestrierung von Web 
Services zu etablieren. Stattdessen konnten in der Vergangenheit eine Reihe von Stan- 
dardisierungsvorschlägen präsentiert werden, die als so genannte „Flow-Languages“ in 
Konkurrenz zueinander stehen. Vgl. Herden et al. (2006), S. 70. Zu den bekanntesten 
Vertretern der Flow-Languages gehören die Business Process Execution Language 
(BPEL), Web Services Flow Language (WSFL), XLANG und Web Service Chore- 
ography Interface (WSCI). Kennzeichnend für diese Sprachen ist ihre Fähigkeit, im Ge- 
gensatz zu WSDL Zustände zu berücksichtigen. 

572 Vgl. Andrews et al. (2003). Im Jahr 2002 wurde BPEL von IBM und MICROSOFT spezi- 
fiziert. Dabei stellt der Standard eine Vereinigung der kalkülbasierten Sprache XLANG 
von MICROSOFT mit den Konzepten der WSFL von IBM dar, indem BPEL die in WSDL 
beschriebenen Web Services zu einem Prozess bündelt. Vgl. Alves et al. (2006). 

573 Vgl. Thomas/Leyking/Dreifus (2007), S. 43. 

574 Vgl. Brodde (2006), S. 22. 


575 Vgl. Modjo Kamneng (2007), S. 292. 
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WMS auf die Middlewaredienste zugreifen, die wiederum die Ausführung der 
Services über die von ihnen bereitgestellte Schnittstelle ermöglichen. 


Anwendungsbezogene Sicht | ‘Anwendungsneutrale Sicht: 
(fachliche Anwendungslogik) ' {Integrationsmechanismen) 


Prozesse : Prozess- führt aus wid tn 
' aktivität oi 
beschreibt 


Services | Service- 
' spezifikation 


gehört zu kommuniziert | | verweist i | 
| bietet über beschreibt auf ae 


Kategorie ge Service- 
ee schnittstelle 
definiert == : 


' 
‘ 
$ 
' 
‘ 


Anwendungs- : | Applikations- o oe Applikations- 
systeme En gruppren Applikation — schnittstelle 


Abbildung 26: Erweiterung des SOA-Architekturmodells um die Prozessebene 


4.2.4 Ebene der Frontendsysteme 


Wie THOME bemerkt, hängt der Nutzen eines IS nicht von der technischen 
Überlegenheit sondern seiner Erreichbarkeit ab.576 Damit die jederzeitige Ver- 
fügbarkeit der Services gewährleistet werden kann, ist in das SOA-Architektur- 
modell eine Ebene einzubetten, die es den Anwendern ermöglicht, auf die Ser- 
vices zuzugreifen. Auf der obersten Schicht des SOA-Architekturmodells ist die 
Ebene der Frontendsysteme positioniert, die auch als Präsentations- und Inter- 
aktionsebene bezeichnet wird. Die Interaktionsebene bildet die Schnittstelle 
zwischen den Servicenutzern und den Services, die in einem Serviceverzeichnis 


576 Vgl. Thome (1998), S. 965. 
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abgelegt sind. Von den hier zum Einsatz kommenden Frontendsystemen sind 
zahlreiche Aufgaben zu erfüllen, die nun skizziert werden. 


Anwendungsbezogene Sicht | ‘Anwendungsneutrale Sicht: 
(fachliche Anwendungslogik) {Integrationsmechanismen) 


Frontend- : | Benutzer- |, unterstützt Portal implementiert | Portal- / CA- 
systeme : aktivität E Plattform 


nutzt - 


en Workflow- 
j X mplementiert 

Prozesse ; Fee führt aus | Workflow p- amer Management- 
| o System 


beschreibt enthält 
Services T- 


verweist | Middleware- 
auf P 
dienste 


i 
i 
' 
‘ 


Anwendungs- Applikations- 
systeme schnittstelle 


Abbildung 27: Erweiterung des SOA-Architekturmodells um die Ebene der 
Frontendsysteme 


Eine Funktionalität der Frontendsystemen liegt darin, den Servicenutzern die re- 
levanten Dienste über eine integrierte und individualisierte Sichtweise zur Ver- 
fügung zu stellen. Dies betrifft sowohl Dienste, die als Stand-Alone- 
Anwendung einzelne Funktionen anbieten, als auch verknüpfte Services, die 
weitere Dienste im Rahmen einer Servicekette auslösen. In gleichem Maße, wie 
sich verschiedene Services aufrufen lassen müssen, ist von der Ebene der Front- 
endsysteme eine Schnittstelle bereitzustellen, damit sich auch unternehmungs- 
externe Dienste in den Servicebestand einbinden lassen. Darüber hinaus ist eine 
Zugriffsfunktion für alle Unternehmungsangehörigen einzurichten, die mit der 
Pflege und Wartung der Services, aber auch weiterer Komponenten einer SOA 
beauftragt sind. Ebenso sind entsprechende Mitarbeiter- bzw. Benutzerrollen für 
Alexander Pastwa - 978-3-631-75488-7 


Downloaded from PubFactory at 01/11/2019 04:20:29AM 
via free access 


Architekturmodell für Serviceorientierte Berichtsprozesse 123 


einen Zugriff auf die Dienste und alle weiteren technischen Komponenten einer 
SOA festzulegen.57’ Die für den Frontendzugriff relevanten Komponenten des 
SOA-Architekturmodells sind in der Abbildung 27 dargestellt. 

Zur Ausführung Serviceorientierter Prozesse werden typischerweise Prozess- 
portale eingesetzt.5’78 Ein Prozessportal ist eine Ausprägung eines Internetpor- 
tals und stellt einen zielgruppenorientierten Zugriff zur Verfügung, um Nutzern 
die Ausführung von Benutzeraktivitäten und die Auslösung von Geschäftspro- 
zessen zu ermöglichen. Damit stellen Prozessportale die Schnittstelle zwischen 
den Anwendungssystemen, den auszuführenden Prozessen und Nutzern dar.579 
Sie sind i. d. R. in Form einer Web-Anwendung realisiert. 

Zur Implementierung von Prozessportalen lassen sich Portal- bzw. 
Composite-Application-Plattformen (CA-Plattformen) einsetzen. Diese stellen 
Entwicklungs- und Laufzeitdienste zur Verfügung, um desktopintegrierte An- 
wendungssysteme zu entwickeln.580 Wie in der Abbildung 27 zu erkennen ist, 
nutzt eine Portalplattform dabei diverse Middlewaredienste. 


4.2.5 Eignung des SOA-Ebenenmodells für Serviceorientierte Berichtspro- 
zesse 


Mit Blick auf die in dieser Arbeit angestrebte Interoperabilität der im Rahmen 
von Berichtsanwendungen eingesetzten IS ist zu konstatieren, dass das vorlie- 
gende Architekturmodell den softwaretechnischen Gestaltungsrahmen liefert, 
um eine Anwendungsintegration kosteneffizient durchzuführen. Zur Herstel- 
lung der Anwendungsinteroperabilität haben die Services eine zentrale Bedeu- 
tung, da sie aus den Realisierungen der vorhandenen Anwendungen gewonnen 
werden können. Auf diese Weise lassen sich in einer SOA beispielsweise Servi- 
ces implementieren, die einen direkten Zugriff auf Daten ermöglichen, die in 
den Anwendungssystemen vorgehalten werden. 

Die Aufteilung des Architekturmodells in die Ebenen der Anwendungssyste- 
me, der Services, der Prozesse und der Frontendsysteme bietet das Potenzial, 
Geschäftsprozesse losgelöst von den sie unterstützenden Anwendungssystemen 
zu betrachten.58! Eine stärkere Trennung von Prozessmanagement und den Ap- 
plikationen bringt in diesem Zusammenhang den Vorteil mit sich, den Fokus 
auf die Gestaltung bzw. auf das Redesign der zu unterstützenden Geschäftspro- 
zesse richten zu können, ohne potenzielle technische Restriktionen beim Model- 


577 Vgl. Heutschi/Legner/Osterle (2006), S. 363. 

578 Vgl. Hansen/Neumann (2005), S. 637. 

579 Vgl. Grimm (2005), S. 17. Generell kommen Internet-Portale zum Einsatz, um ihren 
Nutzern einen direkten Zugang zum Informationsangebot sowie zu diversen Kommuni- 
kationsdiensten des Portal-Betreibers zu ermöglichen. 

580 Vgl. Heutschi (2007), S. 191. 


581 Vgl. Melzer et al. (2007), S. 32; Mattern (2003), S. 35. 
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lierungsprozess in Erwägung ziehen zu miissen.°82 Um die Trennung zwischen 
der Logik der Geschäftsabläufe und den heterogenen und monolithischen An- 
wendungen einer Unternehmung zu überwinden, sind die aus dem Prozessmo- 
dell abgeleiteten Einzelschritte mit den bereits existierenden oder neu zu entwi- 
ckelnden Services zu verknüpfen, um auf diese Weise eine betriebswirtschaftli- 
che Funktion bzw. eine Geschäftsfunktion softwaretechnisch als Service zu 
implementieren.583 Die Inanspruchnahme von Funktionen erfolgt auf Basis ei- 
nes hinterlegten Prozessmodells. Eine wichtige Aufgabe hat in dem entwickel- 
ten Architekturmodell der Einsatz eines WMS, das für die Ausführung und Ko- 
ordination des hinterlegten Prozessmodells zuständig ist. 

Im Ergebnis ist festzuhalten, dass das SOA-Architekturmodell alle techni- 
schen und logischen Komponenten aufführt, mit denen sich eine Automatisie- 
rung und/oder Flexibilisierung von SOBP durchführen lässt. Bei der Betrach- 
tung der Ebenen und ihrer Komponenten muss konstatiert werden, dass eine 
semantische Verarbeitung von Informationen durch die bereitgestellten Kom- 
ponenten nicht gewährleistet wird. ALT/HEUTSCHV/OSTERLE weisen in diesem 
Zusammenhang auf die Notwendigkeit hin, für die Kopplung von IS geeignete 
Standards einzusetzen, die beispielsweise die Berechnungsgrundlage zur Er- 
mittlung eines Unternehmenswerts spezifizieren.°84 

Die im Rahmen des Einsatzes von Web Services thematisierten Standards 
SOAP, WSDL und UDDI reichen in diesem Zusammenhang allerdings nicht 
aus, da sie ausschließlich die technische Ebene fokussieren.585 Um die in Ab- 
schnitt 2.3 diskutierten Problemfelder in den Kernprozessen des Berichtswesens 
zu reduzieren, ist neben der Standardisierung von Prozessen eine weitere wich- 
tige Aufgabe in der Standardisierung von Daten, die im Rahmen einer Service- 
orientierten Anwendung verarbeitet werden sollen, zu erfüllen. Mit XBRL liegt 
die Empfehlung für einen derartigen Standard bereits vor. Da sich dieser expli- 
zit zur semantischen Beschreibung von Geschäfts- und Finanzinformationen, 
die bei der Ausführung von SOBP verarbeitet werden, einsetzen lässt, wird er in 
das hier fokussierte Architekturmodell eingebunden. Damit kann zudem der 
Forderung von BUSCH/DANGELMAIER entsprochen werden. Sie erklären, dass 
für eine softwaretechnische Implementierung von Diensten für einen unterneh- 
mungsübergreifenden Informationsaustausch stets geeignete Standards einzu- 
setzen sind.586 


582 Siehe hierzu die Diskussion verschiedener Vorgehensweisen zur konzeptionellen 
Gestaltung von SOBP in Abschnitt 5.1. 

583 Vgl. hierzu Heuser/Lacher/Perlmann (2007) S. 20. 

584 Vgl. Alt/Heutschi/Osterle (2003), S. 68. 

585 Zu diesen Standards vgl. Abschnitt 3.4. 


586 Vgl. Busch/Dangelmaier (2002), S. 20. 
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4.3 Erweiterung des SOA-Architekturmodells um eine XBRL-Ebene 


Die vorliegenden Ausführungen haben zum Ziel, das bestehende Architektur- 
modell zu erweitern, um bei der Ausführung eines SOBP die Verarbeitung se- 
mantischer Geschäfts- und Finanzinformationen zu ermöglichen. Zu diesem 
Zweck wird das SOA-Ebenenmodell um eine Ebene erweitert. Diese hat den 
Einsatz der Extensible Business Reporting Language (XBRL) zum Gegenstand. 
Hierzu wird in Abschnitt 4.3.1 zunächst ein grundlegendes Verständnis von 
XBRL geschaffen. Den Taxonomien sowie Instanzen als zentrale Bausteine des 
XBRL-Standards widmet sich Abschnitt 4.3.2., während Abschnitt 4.3.3 die 
Einbindung von XBRL in das bestehende SOA-Architekturmodell fokussiert. 


4.3.1 Extensible Business Reporting Language (XBRL) als Enabler eines 
Serviceorientierten Berichtsprozesses 


Gegenstand des vorliegenden Abschnitts ist es, mit XBRL einen gegenwärtig 
weit verbreiteten und anerkannten IT-Standard vorzustellen, der auf der Exten- 
sible Markup Language (XML) aufbaut und als Enabler für einen SOBP zur 
Anwendung kommen kann. Zum Verständnis der Funktionsweise und Nut- 
zungspotenziale von XBRL werden dazu vor allem die konzeptionellen und 
technischen Grundlagen dieses Standards erörtert. Mit Blick auf den XML- 
Charakter von XBRL thematisiert Abschnitt 4.3.1.1 zunächst die charakteristi- 
schen Eigenschaften von XML, die das Interesse an XBRL gefördert haben. 
Darauf aufbauend wird in Abschnitt 4.3.1.2 das für diese Arbeit relevante Ver- 
ständnis von XBRL entwickelt und präzisiert. 


4.3.1.1 XML zur semantischen Beschreibung von Informationen 


Seit der Standardisierung von XML im Jahr 1997 wird der Einsatz dieser Spra- 
che in verschiedenen betriebswirtschaftlichen Anwendungsbereichen disku- 
tiert.587 Als Teilmenge der Standard Generalized Markup Language (SGML) - 
einem international anerkannten Standard zum Aufbau spezifischer Auszeich- 


587 Einsatzmöglichkeiten von XML liegen etwa im Publishing und im Content- 
Management, im elektronischen Handel und in der Unterstützung integrierter Ge- 
schäftsprozesse. Eine Übersicht zu diesen sowie weiteren Einsatzmöglichkeiten und zu 
ausgewählten Praxisbeispielen von XML findet sich bei Schöning (2003), S. 67ff. Für 
die Analyse der Auswirkungen von XML auf Electronic-Commerce-Anwendungen als 


eines der wichtigsten Einsatzfelder von XML vgl. Schinzer/Thome ee) S. 212ff. 
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nungssprachen für elektronische Texte588 — wurde XML vom WORLD WIDE 
WEB CONSORTIUM (W3C) für den Austausch sowie die Ablage von Daten ent- 
wickelt.589 Bei XML handelt es sich um eine erweiterbare Auszeichnungsspra- 
che zur Spezifizierung beliebiger Daten- und Dokumentstrukturen.590 Charakte- 
ristisch für XML ist die Eigenschaft, die in einem XML-Dokument enthaltenen 
Informationen durch die Verwendung geeigneter Auszeichnungselemente, die 
mit Hilfe von Start- und Endtags definiert werden, nach semantischen Gesichts- 
punkten zu beschreiben.5?! Bei der Verarbeitung der Informationen abstrahiert 
XML vollständig von konkreten Darstellungsformen.5?? Die Struktur und das 
Layout werden von dem Inhalt des Dokuments folglich stringent separiert.5%3 
Diese Trennung hat zur Konsequenz, dass sich der Informationsgehalt eines 
XML-Dokuments unabhängig von den Formatierungsanweisungen verarbeiten 
lasst.594 

Mit Blick auf die webgestiitzte Darstellung von Informationen bietet der 
Sprachvorrat der HYPERTEXT MARKUP LANGUAGE (HTML) zwar die Möglich- 
keit, die zu publizierenden Informationen bedarfsgerecht und ,,optisch anspre- 
chend“ auf dem Bildschirm des Informationsempfängers zu visualisieren,595 ei- 
ne inhaltliche Beschreibung der ausgezeichneten Daten findet dabei allerdings 
nicht statt, was als wesentlicher Nachteil von HTML anzusehen ist. Darüber 
hinaus ist eine automatisierte Übernahme von Daten, die in einem HTML- 
Dokument abgelegt sind, nicht unproblematisch, weil HTML keine inhaltlichen 
Beschreibungskonstrukte vorhält, die eine unmittelbare Interpretation der dar- 
gestellten Inhalte zulassen. Vor diesem Hintergrund müssen HTML-Daten ent- 
weder in ein neues Dokument kopiert, direkt in ein Programm geladen oder neu 
eingegeben werden, bevor sie durch die IT weiterverarbeitet werden können.596 
Aufgrund der dabei durchzuführenden Anpassungs- bzw. Transformationsarbei- 


588 Vgl. Schinzer/Thome (1999), S. 209. SGML wurde 1986 von der INTERNATIONAL OR- 
GANISATION FOR STANDARDIZATION (ISO) als Standard verabschiedet (ISO 8879:1986). 
Zur Entwicklung von SGML sowie zum Verhältnis zwischen SGML und XML vgl. 
Eckstein/Eckstein (2004), S. 4f.; Schöning (2003), S. 2f. 

589 Vgl. Leser/Naumann (2007), S. 23. 

590 Vgl. Fellmann/Thomas (2008), S. 972. 

591 Vgl. Fellmann/Thomas (2008), S. 972. 

592 Vgl. Eckstein/Eckstein (2004), S. 8f. 

593 Vgl. Schwalm/Bange (2004), S. 7; Fellmann/Thomas (2008), S. 973. 

594 Vgl. Baars (2005), S. 193. Für Präsentations- bzw. Formatierungszwecke kommen — wie 
auch bei der Anwendung von HTML - so genannte Style Sheets zum Einsatz, die in 
Form von einer Datei oder mehreren Dateien vorliegen können. Vgl. Meyer-Pries/ 
Gröner (2002), S. 45. 

595 An dieser Stelle ist darauf hinzuweisen, dass es sich bei HTML um eine konkrete Aus- 
prägung von SGML handelt, während XML eine Teilmenge von SGML darstellt. Vgl. 
hierzu Schinzer/Thome (1999), S. 209. 


596 Vgl. Meyer-Pries/Gröner (2002), S. 45. 
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ten geht eine derartige Vorgehensweise mit der Gefahr einher, eine schnelle, 
verlässliche und aussagekräftige Berichterstattung zu behindern.>9? 

Die Entwicklung von XML hatte das Ziel, eine Sprache zu schaffen, mit de- 
ren Hilfe sich die Inhalte eines Dokuments automatisiert verarbeiten lassen. Die 
angeführten Schwächen von HTML sollten folglich beseitigt werden,598 wobei 
den so genannten Elementen als Kernbausteine der XML-Syntax eine funda- 
mentale Rolle zukommt.59 Durch sie lassen sich die zu verarbeitenden Inhalte 
eindeutig spezifizieren, indem frei wählbare Elemente eingesetzt werden.600 
Wie Abbildung 28 darstellt, erfolgt die Anordnung der Elemente dabei anhand 
einer hierarchischen Baumstruktur.60! Das in der Abbildung angeführte Beispiel 
zeigt in diesem Kontext die Elemente einiger Posten der Passivseite einer nach 
HGB erstellten Bilanz. Ausgehend von einem Wurzelelement mit der Bezeich- 
nung Passivseite lassen sich weitere Unterelemente in einer verschachtelten 
Struktur anordnen, um die Werte der jeweiligen Bilanzposten der Passivseite zu 
beschreiben.602 

Die XML-Syntax schreibt den Einsatz derartiger Elemente zur semantischen 
Auszeichnung vor. Im Gegensatz zu HTML ist die exakte Bezeichnung der zu 
verwendenden Elemente nicht vorgegeben. Mit Blick auf die freie Wählbarkeit 
der Elemente lassen sich diese je nach Anwendungsbereich also flexibel defi- 
nieren.603 Vor dem Hintergrund dieser Eigenschaft sowie der sämtlichen XML- 
Dokumenten zugrunde liegenden hierarchischen Datenstruktur ermöglicht diese 
Sprache, dass die Inhalte nicht nur maschinell verarbeitet, sondern auch von den 
menschlichen Aufgabenträgern verstanden bzw. interpretiert werden können. 
Die in einem XML-Dokument beschriebenen Inhalte sind dabei nicht auf die 
semantische Auszeichnung strukturierter Inhalte beschränkt. In gleichem Maße 
lassen sich auch unstrukturierte und verschiedenartige multimediale Inhalte dar- 
stellen. 


597 Vgl. hierzu die in Abschnitt 2.3 diskutierten Problemfelder für ein effektives und effi- 
zientes Reporting. 

598 Zum Zusammenhang zwischen HTML und XML vgl. Kazakos/Schmidt/Tomczyk 
(2002), S. 8f.; Schinzer/Thome (1999), S. 208f. Zur Entstehung sowie zu den Entwurfs- 
zielen von XML vgl. Klettke/Meyer (2003), S. 21f. 

599 Vgl. Eckstein/Eckstein (2004), S. 20; Klettke/Meyer (2003), S. 24. Die Autoren liefern 
ferner eine Einführung in den syntaktischen Aufbau von XML-Dokumenten sowie die 
damit verbundene Verwendung der Elemente. Vgl. Eckstein/Eckstein (2004), S. 19ff.; 
Klettke/Meyer (2003), S. 24ff. 

600 Vgl. Schöning (2003), S. 4f. 

601 Vgl. Klettke/Meyer (2003), S. 24. 

602 In Abbildung 28 wird deutlich, dass zur semantischen Auszeichnung des Inhalts — bei- 
spielsweise von 5.000.000 im Fall des gezeichneten Kapitals — ein Start- sowie ein End- 
tag des jeweiligen Elements verwendet werden. 

603 Hierin liegt nach MARTENS ET AL. ein wichtiger Faktor für den Erfolg von XML. Vgl. 


Martens et al. (2006), S. 771. 
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<Passivseite> 
<Eigenkapital> 
<Gezeichnetes_Kapital>5.000.000</Gezeichnetes_Kapital> 
<Kapitalrücklagen>1.000.000</Kapitalrücklagen> 
<Gewinnrücklagen>1.500.000</Gewinnrücklagen> 


</Eigenkapital> 

<Rückstellungen>...</Rückstellungen> 

<Verbindlichkeiten>...</Verbindlichkeiten> 

<Rechnungsabgrenzungsposten>...</Rechnungsabgrenzungsposten> 
</Passivseite> 


Abbildung 28: Beispiel fiir ein XML-Dokument 


Zusammenfassend lässt sich festhalten,60 dass sich die Potenziale von XML 
vor allem beim Datenaustausch und bei persistenten Datenablagen entfalten.605 
Als Schnittstellenstandard eröffnet XML damit diverse Einsatzmöglichkeiten, 
wobei der Standard insbesondere bei solchen Aufgaben zum Einsatz kommt, die 
eine web- und semantikgestützte sowie automatisierte Datenverarbeitung erfor- 
dern. Die Flexibilität und die Unabhängigkeit von bestimmten Anwendungs- 
domänen erweisen sich hier als besondere Stärken. 


4.3.1.2 Definition von XBRL 


Die (Weiter-)Entwicklung von XBRL in den vergangenen Jahren war von dem 
Ziel geleitet, sich der Stärken von XML für die Zwecke des Unternehmensre- 
portings zu bedienen.606 Mit XBRL sollte ein Standard geschaffen werden, mit 
dessen Hilfe sich Geschäfts- und Finanzinformationen semantisch beschreiben 
sowie effizient und effektiv (weiter-)verarbeiten lassen. Um die zu verarbeiten- 
den Geschäfts- und Finanzinformationen mit einer Bedeutung auszeichnen zu 
können, musste ein Vorrat an Elementen mit entsprechenden Beziehungs- 
strukturen festgelegt werden, die sich für diese Zwecke nutzen lassen. 

Unter der Dachorganisation XBRL INTERNATIONAL entstanden in diesem Zu- 
sammenhang verschiedene Divisionen, welche die nationale sowie internationa- 


604 Da die Nutzenpotenziale von XML in der Literatur hinreichend ausgearbeitet wurden, 
erfolgt an dieser Stelle nur eine kurze Zusammenfassung der wichtigsten Aspekte. Eine 
Vorstellung der Nutzenpotenziale von XML liefert z. B. Schöning (2003), S. 62ff. 

605 Vgl. Gabriel/Röhrs (2003), S. 396; Leser/Naumann (2007), S. 23. 

606 Zur Geschichte sowie zu den Entwicklungsschritten von XBRL vgl. DeFelice (2007), S. 


30f. 
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le Etablierung von XBRL als Kommunikations- und Reportingstandard forcier- 
ten. Diese entsprechen meist Zusammenschlüssen von Software- und Bera- 
tungsunternehmungen, Forschungseinrichtungen und Anwenderunternehmun- 
gen, welche die (Weiter-)Entwicklung von XBRL aktiv vorantreiben.607 

Als XML-Dialekt verfügt XBRL über alle Eigenschaften, die sich aus der 
vom W3C propagierten Spezifizierung zur Meta-Sprache XML ergeben.®8 Als 
Synthese einiger ausgewählter Definitionsvorschläge lässt sich XBRL als frei 
verfügbarer, plattform- und systemunabhängiger (technologieunabhängiger) 
Open-Source-Kommunikationsstandard für die automatisierte und software- 
unterstützte Erstellung, Verbreitung, Veröffentlichung und Auswertung von 
monetären und nicht monetären Geschäfts- und Finanzinformationen verste- 
hen.609 Da XBRL als kostenfreier und offener Standard zur Verfügung steht, 
unterliegt die Spezifikation nicht der Marktmacht einer einzelnen Unterneh- 
mung. 


4.3.2 Bausteine des XBRL-Standards 


Die Standardisierungsempfehlung zu XBRL setzt sich aus zwei Bausteinen zu- 
sammen. Bei diesen handelt es sich zum einem um die XBRL-Taxonomien, 
zum anderen um die XBRL-Instanzen.6!0 Die Vorstellung beider Bestandteile 
ist Gegenstand der Abschnitte 4.3.2.1 und 4.3.2.2. 


4.3.2.1 XBRL-Taxonomie 


In einem allgemeinen Verständnis lässt sich eine Taxonomie als ein vorher fest- 
gelegtes, hierarchisches Schema definieren, das dazu dient, Informationen zu 
klassifizieren bzw. kategorisieren.6!! Durch die Segmentierung sprachlicher 
Einheiten lässt sich auf diese Weise ein domänenspezifisches Sprachsystem an- 
legen, das für die Verarbeitung von Informationen der jeweiligen Anwendungs- 
domäne verwendet werden kann.612 Im Kontext von XBRL kommen mit dem 
XBRL-Schema und den XBRL-Linkbases zwei Bausteine einer XBRL- 
Taxonomie zum Einsatz, deren Grundlagen in den Abschnitten 4.3.2.1.1 und 
4.3.2.1.2 vertieft werden. 


607 Vgl. XBRL International (2009); Hodge/Kennedy/Maines (2004), S. 688. 

608 Vgl. Eccles/Watson/Willis (2007), S. 207; Helmerich/Hümpfner/Scherer (2004), S. 623; 
Meall (2007), S. 73f. 

609 Diese Definition basiert auf den Darstellungen von Baars (2005), S. 193; Felden (2006), 
S. 32; Meyer-Pries/Gröner (2002), S. 45; Pandrangi (2003); Schwalm/Bange (2004), S. 
10. 

610 Vgl. hierzu Hannon (2005), S. 58. 

611 Vgl. Laudon/Laudon/Schoder (2006), S. 464. 


612 Vgl. hierzu Grothe/Gentsch (2000), S. 218. 
Alexander Pastwa - 978-3-631-75488-7 


Downloaded from PubFactory at 01/11/2019 04:20:29AM 
via free access 


130 Erweiterung des SOA-Architekturmodells um eine XBRL-Ebene 


4.3.2.1.1 XBRL-Schema als Normierungs- und Strukturvorschrift einer 
XBRL-Taxonomie 


Da sich XML durch eine hohe Flexibilität bzw. Erweiterbarkeit auszeichnet, 
muss definiert werden, welche Dokumentinhalte und -strukturen in dem jewei- 
ligen Anwendungsbereich, in dem das Schema genutzt werden soll, zugelassen 
sind.613 Mit Hilfe von XML-Schema lassen sich alle Elemente sowie Attribute 
einer Anwendungsdomäne vollständig, systematisch und strukturiert spezifizie- 
ren.614 Die Attribute werden dabei verwendet, um den zulässigen Wertebereich 
der Elemente festzulegen.6!5 Die daraus resultierende Vorschrift wiederum lie- 
fert eine anwendungsspezifische Schablone bzw. Grammatik zur Erstellung und 
Validierung von so genannten Instanzdokumenten, deren Elemente, Attribute 
sowie Werteinträge den Vorgaben des jeweiligen XML-Schemas genügen müs- 
sen.616 Auf diese Weise lässt sich die syntaktische Korrektheit der XML- 
Instanzdokumente konsequent sicherstellen.617 

Im Zusammenhang mit XBRL ist innerhalb eines XBRL-Schemas vorgege- 
ben, welche Konzepte sich zur semantischen Auszeichnung der Geschäfts- und 
Finanzinformationen verwenden lassen.618 Die Konzepte werden durch die 
Elemente repräsentiert. Alternativ werden die Elemente auch als Items sowie In- 
formationseinheiten bezeichnet.619 Wie in der Abbildung 29 am Beispiel des Bi- 
lanzpostens Bruttoumsatz (Gross Profit) verdeutlicht ist, werden zur Beschrei- 
bung der Elemente verschiedene Attribute verwendet. Neben dem Elementna- 
men (name=“GrossProfit‘“) und einer ID (id=“ifrs-gp GrossProfit‘), die zur 


613 Vgl. Martens et al. (2006), S. 771. 

614 Vgl. Schöning (2003), S. 33. Die Verabschiedung des XML-Schemas durch das W3C 
erfolgte im Mai 2001. Vgl. Klettke/Meyer (2003), S. 115. Eine Alternative zum Einsatz 
des XML-Schemas sind so genannte Document-Type-Definitions (DTD). Da DTD im 
Vergleich zu einem XML-Schema nur eingeschränkte Nutzungsmöglichkeiten haben, 
wird aktuell verstärkt das XML-Schema zur Gestaltung XML-basierter Anwendungen 
genutzt. Zu den Einschränkungen von DTD vgl. Martens et al. (2006), S. 771. Eine 
Übersicht über die im Vergleich zu DTD umfangreicheren Darstellungsmöglichkeiten 
des XML-Schemas liefern Klettke/Meyer (2003), S. 115ff. 

615 Vgl. Eckstein/Eckstein (2004), S. 83. 

616 Eine Einführung in die grundlegenden Konzepte von XML-Schema präsentieren unter 
anderem ECKSTEIN/ECKSTEN und KAZAKOS/SCHMIDT/TOMCZYK. Vgl. Eckstein/ 
Eckstein (2004), S. 83ff.; Kazakos/Schmidt/Tomczyk (2002), S. 39ff. 

617 Vgl. Fellmann/Thomas (2008), S. 974. Syntaktisch korrekte XML-Dokumente werden 
auch als ,,wohlgeformt“ (well-formed) bezeichnet. Zu den Eigenschaften wohlgeformter 
XML-Dokumente vgl. z. B. Klettke/Meyer (2003), S. 38f. Gültige bzw. valide XML- 
Dokumente genügen darüber hinaus Regeln, die die Nutzung von bestimmten Elemen- 
ten und Attributen in einem XML-Dokument definieren. Derartige Regeln sind im 
XML-Schema spezifiziert. Vgl. Fellmann/Thomas (2008), S. 974. 

618 Vgl. Baars (2005), S. 193; Kranich/Schmitz (2003), S. 77f. 


619 Vgl. Kranich/Schmitz (2003), S. 78. 
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eindeutigen Kennzeichnung dieses Elements dienen, lassen sich weitere Attri- 
bute nutzen. Die vorlaufende Bezeichnung “ifrs-gp“ deutet darauf hin, dass das 
GrossProfit-Element im Rahmen der IFRS-General-Purpose-Taxonomie spezi- 
fiziert ist.620 


name "GrossProfit" 


type "monetaryltemType" 


periodType “duration” 
abstract h 


Abbildung 29: Ausgewählte Attribute eines XBRL-Taxonomieelements 


Mit Hilfe des type-Attributs wird der Datentyp für das jeweilige Element festge- 
legt. Bei dem hier betrachteten Taxonomieelement kommt mit “monetaryltem- 
Type“ ein Datentyp für Währungsbeträge zum Einsatz. Das Attribut mit der Be- 
zeichnung periodType gibt Auskunft darüber, ob es sich bei dem betrachteten 
Element um eine Strom- oder Bestandsgröße handelt, während das balance- 
Attribut informiert, ob das jeweilige Element auf der Aktivseite (“debit‘‘) oder 
Passivseite (“credit‘) steht. Hat das abstract-Attribut eines XBRL-Elements den 
Wert “false“, kann es instanziert werden.62! Mit Hilfe des nillable-Attributs 
lässt sich festlegen, ob das Element Nullwerte aufnehmen kann.622 Ist diese Ei- 
genschaft — wie in dem vorliegenden Fall — erfüllt, weist das Attribut einen po- 
sitiven Wert (“true“) auf. 


620 Vgl. hierzu IASB (2005). 
621 Vgl. hierzu Eckstein/Eckstein (2004), S. 153. 


622 Vgl. hierzu Eckstein/Eckstein (2004), S. 136. 
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4.3.2.1.2 Beziehungstypen einer Taxonomie 


Zur Abbildung einer konsistenten Sicht auf die Geschäftszahlen einer Unter- 
nehmung ist es notwendig, die in einer Taxonomie definierten Elemente mitein- 
ander zu verknüpfen, um auf diese Weise Zusammenhänge abzubilden. So muss 
beispielsweise definiert sein, dass sich eine Bilanz aus einer Aktiv- und Passiv- 
seite zusammensetzt, welche wiederum ergänzende Bilanzpositionen enthalten. 
Zur Beschreibung der jeweiligen Beziehungsstrukturen stehen dem Entwickler 
einer XBRL-basierten Anwendung mit den Definition Links (Definition), Cal- 
culation Links (Berechnung), Presentation Links (Darstellung), Label Links 
(Bezeichnung) und Reference Links (Referenz) fünf Beziehungstypen zur Ver- 
fügung.623 Anstelle des Terminus „Links“ ist auch die Bezeichnung ,,Linkbase“ 
gebräuchlich. Linkbases lassen sich als separate XML-Dokumente auffassen,®24 
die alle Anweisungen des jeweiligen Beziehungstyps beinhalten.625 Die fünf 
Beziehungstypen gliedern sich in zwei Beziehungsklassen — Relation Links und 
Documentation Links. 

Die Beziehungsklasse Relation Links umfasst alle Beziehungstypen, die in- 
nerhalb einer Taxonomie zwischen den darin enthaltenen Elementen auftreten. 
Hierzu gehören die Beziehungstypen Definition Links, Calculation Links sowie 
Presentation Links. Der Beziehungstyp Definition Links dient dazu, die inhaltli- 
che Zuordnung der Elemente in einer Taxonomie in Form hierarchischer Bezie- 
hungsstrukturen festzulegen.626 Auf diese Weise ist beispielsweise definiert, 
dass die Bilanzpositionen Vorräte und Kassenbestand zum Umlaufvermögen 
gehören. Calculation Links werden zur rechentechnischen Abbildung der Ele- 
mentbeziehungen eingesetzt.62? Im Falle einer additiven Verknüpfung lassen 
sich die Werte untergeordneter Bilanzpositionen durch den Einsatz dieses Be- 
ziehungstyps zu einer übergeordneten Bilanzposition addieren. Alternativ kön- 
nen untergeordnete Elemente voneinander abgezogen werden, um ein neues 
übergeordnetes Ergebnis zu generieren. In der Kategorie der Presentation Links 
als letzte Ausprägung einer Relation Links-Beziehungsklasse wird festgelegt, in 
welcher Reihenfolge die einzelnen XBRL-Elemente angezeigt werden sollen.628 


623 Vgl. Felden (2006), S. 33; Gehra/Hess (2004), S. 403; Kranich/Schmitz (2003), S. 78. 

624 Zur Definition der verschiedenen Link-Arten kommt die XML-Linking-Technologie 
(XLink) zum Einsatz. Sie wird eingesetzt, um Beziehungen zwischen Informationsein- 
heiten sowie Referenzen zu externern Ressourcen zu spezifizieren. Vgl. Felden (2006), 
S. 33. 

625 Vgl. Ramin/Kesselmeyer/Ott (2006a), S. 183. 

626 Vgl. Baars (2005), S. 193. 

627 Vgl. Baars (2005), S. 193. 


628 Vgl. Ramin/Kesselmeyer/Ott (2006b), S. 12. 
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Bei diesem Beziehungstyp geht es folglich um die Strukturierung der Elemente 
nach logischen Gesichtspunkten.629 

Die Beziehungsklassen Label Links und Reference Links, die zur Bezie- 
hungsklasse der Documentation Linkbases gehören, verfolgen das Ziel, die Be- 
standteile einer Taxonomie mit zusätzlichen Informationen anzureichern, um 
damit die Aussagekraft der Geschäfts- und Finanzinformationen zu steigern.630 
Mit Hilfe der Label Links lassen sich den Konzepten einer Taxonomie Bezeich- 
nungen in verschiedenen Sprachen zuweisen.63! Auf diesem Weg lässt sich eine 
Mehrsprachigkeit abbilden, so dass für den Bilanzposten Umlaufvermögen das 
Pendant “Current Assets“, “Actifs Circulants“ oder “Activo Circulante“ in der 
jeweiligen englischen, französischen und italienischen Landessprache benutzt 
werden kann. Die Beziehungsklasse Reference Links kommt zur Anwendung, 
um z. B. Verweise auf eine Rechtsquelle als gesetzliche Grundlage oder auf ei- 
ne maßgebende Literatur für ein XBRL-Element anzulegen. Entsprechend kann 
ein besseres Verständnis für das verwendete Konzept erzielt werden. 


4.3.2.2 Taxonomiekategorien von XBRL 


Je nach Informationsbedarf des Empfangers hinsichtlich des Detaillierungs- 
grads der zu verarbeitenden Inhalte einer XBRL-Instanz lassen sich mit XBRL 
Global Ledger (XBRL GL) und XBRL Financial Reporting (XBRL FR) zwei 
Taxonomiekategorien einsetzen. Beide Taxonomiekategorien werden in den 
Abschnitten 4.3.2.2.1 und 4.3.2.2.2 vorgestellt. 


4.3.2.2.1 XBRL Financial Reporting 


Die XBRL FR-Taxonomien wurden mit dem Ziel entwickelt, den Austausch 
aggregierter bzw. konsolidierter Geschäfts- und Finanzinformationen, wie sie 
beispielsweise in Form eines Jahresabschlusses veröffentlicht werden, zu unter- 
stützen. In den vergangenen Jahren ist es der Dachorganisation XBRL INTER- 
NATIONAL gelungen, eine Reihe von XBRL FR-Taxonomien zu erstellen und 
zur freien Nutzung anzubieten.632 

Dem Anwender stehen Taxonomien zur Verfügung, in denen gegenwärtig 
etablierte Rechnungslegungsstandards wie beispielsweise IAS/IFRS, US-GAAP 
oder HGB abgebildet sind. Für jeden Bestandteil dieser Standards ist dabei typi- 
scherweise eine separate Taxonomie publiziert, wobei eine vollständige HGB- 


629 Vgl. Felden (2006), S. 33. 

630 Vgl. Baars (2005), S. 193. 

631 Vgl. Ramin/Kesselmeyer/Ott (2006b), S. 12. 

632 Eine Übersicht zu den vorhandenen Taxonomien ist unter XBRL INTERNATIONAL abruf- 


bar. Vgl. XBRL International (2009). 
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Abschluss-Taxonomie z.B. die Bereiche „Allgemeine Informationen“, „Bi- 
lanz“, „GuV-Rechnung‘“, „Ergebnisverwendung‘“, „Eigenkapitalspiegel“, „Kapi- 
talflussrechnung“, „Anlagespiegel“, ,,Segmentberichterstattung“, „Liste des An- 
teilsbesitzes“, „sonstige Notes“, „Lagebericht“ sowie „Einladung/Topics der 
Hauptversammlung“ beinhaltet.633 

Neben Taxonomien zur Abbildung der landesspezifischen Rechnungsle- 
gungsstandards liegen darüber hinaus Taxonomien vor, die sich innerhalb eines 
Rechnungslegungsstandards auf die Weiterverarbeitung von Geschäfts- und Fi- 
nanzinformationen in spezifischen Branchen beziehen.63* Exemplarisch sind in 
diesem Zusammenhang die „Commercial and Industrial-Taxonomie“ sowie die 
„Banking and Savings-Taxonomie“ zu nennen, die im ersten Fall für die Fi- 
nanzberichterstattung von Handels- und Industrieunternehmungen, im zweiten 
Fall für das Reporting von Unternehmungen aus dem Bankensektor eingesetzt 
werden können. Während die Taxonomien zu IAS/IFRS sowie US-GAAP einen 
derartigen Branchenbezug aufweisen, liegt eine dementsprechende Ausrichtung 
bei der aktuell vorhandenen HGB-Taxonomie nicht vor. 


4.3.2.2.2 XBRL Global Ledger 


Im Vergleich zu den XBRL FR-Taxonomien fokussiert XBRL GL nicht die 
Verarbeitung konsolidierter bzw. aggregierter Daten, die beispielsweise in einer 
Bilanz enthalten sind. XBRL GL lässt sich einsetzen, um Geschäfts- und Fi- 
nanzdaten semantisch zu verarbeiten, die in einer geringeren Verdichtungsstufe 
vorliegen und damit als Grundlage fiir die Erstellung eines Jahresabschlusses 
dienen.®35 Gegenstand des Datenaustauschprozesses sowie der Datenspeiche- 
rung unter Einsatz von XBRL GL sind folglich alle Daten, die in den Buchhal- 
tungs- und Kostenrechnungssystemen einer Unternehmung verarbeitet wer- 
den.636 Unter Einsatz der XBRL GL-Taxonomie wird angestrebt, alle Haupt- 
bucheinträge und entsprechenden Konten zu erfassen.637 Das Anwendungsfeld 
ist hierbei nicht auf finanzielle Daten beschränkt, sondern kann auch nicht fi- 
nanzielle Daten umfassen.633 

Im Gegensatz zu den XBRL FR-Taxonomien sind bei der XBRL GL- 
Taxonomie keine Elemente fiir einen bestimmten Rechnungslegungsstandard 
oder Bestandteil des Jahresabschlusses vorgegeben.639 Stattdessen liefert XBRL 


633 Vgl. Meyer-Pries/Gröner (2002), S. 47f. 

634 Vgl. Kranich/Schmitz (2003), S. 78. 

635 Vgl. Kranich/Schmitz (2003), S. 79; Meyer-Pries/Gröner (2002), S. 45; Garbellotto 
(20063), S. 59. 

636 Vgl. Ramin/Kesselmeyer/Ott (2006a), S. 183. 

637 Vgl. Kranich/Schmitz (2003), S. 79. 

638 Vgl. Garbellotto (2006a), S. 59. 


639 Vgl. Ramin/Kesselmeyer/Ott (2006a), S. 181. 
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GL den Rahmen, wie Buchungen sowie Transaktionsdaten semantisch auszu- 
zeichnen und für einen Datenaustausch auf Basis von XBRL vorzubereiten 
sind. Auf diese Weise können diese Daten unabhängig von einem Rechnungsle- 
gungsstandard zwischen unternehmungsinternen und -externen XBRL- 
kompatiblen IS ausgetauscht sowie gespeichert werden.640 Darüber hinaus las- 
sen sich in den semantisch ausgezeichneten Buchungen über die Verwendung 
zusätzlicher Datenfelder Querverweise auf eine übergeordnete Bilanzposition 
herstellen, die wiederum als Element in einer XBRL FR-Taxonomie definiert 
ist.641 

Die XBRL GL-Taxonomie setzt sich aus einem Basismodul, das als Core 
(COR) bezeichnet wird, und vier Erweiterungen zusammen, mit deren Hilfe sich 
die Buchungs- bzw. Transaktionsdaten mit ergänzenden Informationen anrei- 
chern lassen.642 

Wie in Abbildung 30 erkennbar ist, liegt dem Einsatz von XBRL GL die 
Prämisse zugrunde, dass alle zum Austausch vorgesehenen Daten in einem Bu- 
chungsprotokoll abgelegt sind. Dieses ist im jeweiligen Buchhaltungssystem 
vorzuhalten.6%3 Für den Austausch eines derartigen Buchungsprotokolls liefert 
das Basismodul COR von XBRL GL alle notwendigen Informationen. Alle in 
einem derartigen Protokoll abgelegten Daten werden als eine Gruppe von Bu- 
chungen aufgefasst. Diese Daten werden in der Sprache von XBRL GL „accou- 
tingEntries“ genannt und bestehen aus einer oder mehreren Buchungssätzen 
(„entryHeader“), die sich wiederum aus einer oder mehrerer Buchungen zu- 
sammensetzen (,„entryDetail‘).6* 


640 Vgl. Ramin/Kesselmeyer/Ott (2006a), S. 183. 

641 Vgl. Kranich/Schmitz (2003), S. 79; Garbellotto (2006a), S. 59. Die Verknüpfung von 
XBRL GL und XBRL FR lässt sich mit Hilfe der Datenfelder xbrITaxonomy sowie 
xbrlElement durchführen. Vgl. Ramin/Kesselmeyer/Ott (2006a), S. 183. 

642 Bei den Erweiterungen von COR handelt es sich um Module, welche die Bezeichnung 
Advanced Business Concepts (BUS), MultiCurrency (MUC), Concepts for the US, UK, 
etc. (USK) und Tax Audit File (TAF) tragen. Das BUS-Modul liefert Datenfelder, mit 
denen der Organisationsaufbau einer Unternehmung sowie weitere messbare Daten be- 
schrieben werden können. In diesem Kontext lassen sich die Elemente einerseits zur 
Eingabe von Detaildaten z. B. im Anlagevermögen oder Vorratsvermögen nutzen. An- 
dererseits können auch Kennzahlen wie beispielsweise Key-Performance-Indikatoren 
semantisch ausgezeichnet werden. Das MUC-Modul ergänzt das Basismodul um Ele- 
mente zur Währungsumrechnung. Das USK-Modul enthält Datenfelder, die tendenziell 
bei angelsächsisch geprägten Buchführungssystemen zum Einsatz kommen wie etwa der 
Aufriss der Debitorenkonten. Die Elemente aus dem TAF-Modul ermöglichen hingegen 
eine steuerliche Betriebsprüfung. 

643 Vgl. Ramin/Kesselmeyer/Ott (2006a), S. 184. 

644 Die Elemente des COR-Basismoduls liefern zu den einzelnen Buchungen Angaben zu 
den Buchungskonten (account), zu der gebuchten Menge (amount) sowie zu der Bu- 


chungszeit (postingDate). 
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accountingEntries 
3 


entityInformation 


2 m ax ce Joumalizing Name: 
entryHeader : Journalizing Summary 
debit credit note 


i entryDetail : Cash 1200 | [raana 
Aue Sales 1200 Invoice 234 
entryDetail : | i 


Abbildung 30: Aufbau von XBRL GL®5 


Neben den Buchungssätzen lassen sich in den „accountingEntries“ auch Sum- 
men- und Saldenlisten (balance), Buchungsjournale (journal) oder Saldenlisten 
einzelner Konten (ledger) abbilden. Darüber hinaus können auch weitere Infor- 
mationen eingefügt werden, die indirekt aus der Buchhaltung stammen bzw. 
dem Hauptbuch vorgelagert sind.646 Zu diesen Informationen gehören z. B. Of- 
fene-Posten-Listen, Vorratsinventarlisten oder der Anlagespiegel. 


4.3.2.3  Werttragende Instanzdokumente 


Während Taxonomien die inhaltlichen sowie strukturellen Vorgaben zur Ver- 
wendung von Konzepten des betrieblichen Berichtswesens enthalten, besitzen 
XBRL-Instanzdokumente die Aufgabe, die konkreten Berichtsdaten im XML- 
Format vorzuhalten.64’ Vor diesem Hintergrund lassen sich XBRL-Instanzen als 
werttragende Ausprägungen einer XBRL-Taxonomie bezeichnen.64# Die 
XBRL-Taxonomie dient dabei als Referenz bzw. Grammatik für das Instanzdo- 
kument. Dies hat zur Folge, dass eine valide XBRL-Instanz, die eine bestimmte 
XBRL-Taxonomie referenziert, die in der Taxonomie normierten Elemente, die 


645 In Anlehnung an Ramin/Kesselmeyer/Ott (2006a), S. 184. 

646 Vgl. Ramin/Kesselmeyer/Ott (2006a), S. 184. 

647 Vgl. Baars (2005), S. 193; Pandrangi (2003). 

648 MEYER-PRIES/GRÖNER sprechen in diesem Zusammenhang auch von einem „elektroni- 


schen“ Report. Vgl. Meyer-Pries/Gröner (2002), S. 49. 
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Attribute ebenso wie die Beziehungen zwischen den Elementen enthalten 
muss.649 


<ifrs_gp:GrossProfit 
contextRef="Current_for_Period” 
unitRef="U-Euros" 
decimals="0">850000 

</ifrs_gp:GrossProfit> 


<unit id="U-Euros"> 
<measure>iso4217:EUR</measure> 
</unit> 


<context id="Current_for_Period"> 
<entity> 
<identifer scheme="www.company.com">SAMP 
</identifier> 
</entity> 
<period> 
<startDate>2007-01-01</startDate> 
<endDate>2007-12-31</endDate> 
</period> 
</context> 


Abbildung 31: Beispiel eines XBRL-Instanzdokuments 


Abbildung 31 stellt den Aufbau sowie einen Auszug des möglichen Inhalts ei- 
nes XBRL-Instanzdokuments dar. Wie aus der Abbildung hervorgeht, enthält 
das Instanzdokument eine Reihe von Elementen, Attributen und Werten. Neben 
der Bezeichnung für das verwendete Taxonomieelement (GrossProfit) sind wei- 
tere Attribute zur Konkretisierung der Inhalte dieses Elements abgelegt. 

Im gewählten Beispiel enthält das Instanzdokument einen Eintrag von 
850.000, der für die Höhe des Bruttogewinns steht. Aus dem Präfix “ifrs_gp“ 
geht hervor, dass das GrossProfit-Element zu einem Namensraum für Schema- 
elemente gehört, die in der IFRS-General-Purpose-Taxonomie spezifiziert 


649 Vgl. Meyer-Pries/Gröner (2002), S. 49. 
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sind.650 Die Attribute unitref und contextref repräsentieren Verweise auf das 
unit- und context-Element, die wiederum weitere Unterelemente, Eigenschaften 
und Inhalte umfassen. Während das unit-Element eine Angabe über die zum 
Einsatz kommende Währung liefert, informiert das context-Element über die 
Gültigkeit dieses Eintrags, was über ein diesbezügliches Anfangs- (startdate- 
Element) und Enddatum (enddate-Element) dargestellt wird. Ferner ist aus dem 
illustrierten Beispiel ableitbar, dass sich der Bruttogewinn auf das Geschäftsjahr 
2007 bezieht. Dabei handelt es sich um einen Eurobetrag, welcher keine Dezi- 
malstellen zulässt. Letztere Angabe wird über das decimals-Attribut bestimmt. 


Operative 
IS 


Analyse- 
orientierte 
IS 


Abbildung 32: Nutzungsmöglichen von XBRL®5! 


Es lässt sich zusammenfassen, dass XBRL sowohl zur Verarbeitung operativer 
Berichtsdaten als auch zur Verarbeitung von Daten eingesetzt werden kann, die 
in Analyseorientierten IS (wie z. B. in DWH-Anwendungen) vorgehalten wer- 
den. Wie Abbildung 32 zeigt, ergeben sich hinsichtlich der Anwendungsmög- 
lichkeiten von XBRL zahlreiche Einsatzfelder, wobei als nationale und interna- 
tionale Adressaten eines Reportings auf Basis von XBRL die Shareholder einer 


650 Vgl. hierzu IASB (2005). 


651 In Anlehnung an Oehler (2006), S. 109. 
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Unternehmung genauso in Frage kommen, wie ihre Stakeholder.65? Dabei bringt 
XBRL die Möglichkeit mit sich, dass sich der Standard sowohl für die Zwecke 
des internen als auch externen Reportings einsetzen lässt.653 


4.3.3 Einbindung der XBRL-Konzepte in das SOA-Ebenenmodell 


Abbildung 33 verdeutlicht das vollständige Architekturmodell, das sich zur 
konzeptionellen Gestaltung eines SOBP nutzen lässt. Festzuhalten ist, dass die 
XBRL-Ebene zwischen der Ebene der Anwendungssysteme und der Service- 
ebene positioniert ist. Als Architekturkomponenten der XBRL-Ebene kommen 
die XBRL-Taxonomien und die XBRL-Instanzen zum Einsatz. 

Wie aus der Abbildung deutlich wird, dienen die XBRL-Taxonomien als Re- 
ferenz für die XBRL-Instanzen. Mit Blick auf die kombinierte Verwendung von 
XBRL und Services ergeben sich zwei Nutzungsmöglichkeiten. Zum einen 
können Services direkt auf die Daten eines XBRL-Instanzdokuments zugreifen. 
In diesem Fall kommen XBRL-Instanzen als Informationsquelle für die Servi- 
ces zum Einsatz. Zum anderen ist es möglich, dass Dienste direkt die Daten der 
Anwendungssysteme verarbeiten. Wie beim Zugriff eines Services auf ein 
XBRL-Instanzdokument dienen die XBRL-Taxonomien in dieser Konstellation 
als Validierungsinstrument, das sicherstellt, dass nur Geschäfts- und Finanzin- 
formationen verarbeitet werden, die zuvor durch die Zuweisung eines XBRL- 
Taxonomieelements semantisch beschrieben wurden. 

Damit sich XBRL und Services kombiniert nutzen lassen, ist im Rahmen ei- 
nes als Mapping bezeichneten Vorgangs einmalig festzulegen,65% welche Objek- 
te eines datenvorhaltenden IS mit welchen korrespondierenden Elementen einer 
in XBRL vorliegenden FR- oder GL-Taxonomie verknüpft werden können.s5> 
Anschließend lassen sich aus dem IS die werttragenden Instanzdokumente un- 
mittelbar erstellen.656 Nahezu alle führenden Datenbankhersteller haben eine 
derartige XML-Schnittstelle in ihre relationalen, objektrelationalen oder objekt- 
orientierten Produkte integriert. Nahe liegend erscheint darüber hinaus die Nut- 
zung eines reinen XML-Datenbanksystems, das naturgemäß für die Speiche- 
rung von XML-Daten prädestiniert ist.657 In umgekehrter Weise bietet es sich 


652 Zu den betriebswirtschaftlichen Einsatzmöglichkeiten von XBRL vgl. Gabriel/ 
Gluchowski/Pastwa (2006), S. 942f. 

653 Vgl. Bovee et al. (2002), S. 166; Kemper/Mehanna/Unger (2004), S. 131. 

654 Vgl. Dorloff/Leukel/Schmitz (2004a), S. 89f.; Dorloff/Leukel/Schmitz (2004b), S. 341f. 

655 Als Softwareunterstützung werden für diesen Zweck so genannte Mapping-Tools einge- 
setzt. 

656 Vgl. Nutz/Strauß (2002), S. 454. 

657 Zur XML-Unterstützung in Datenbanksystemen vgl. z. B. Schöning (2003), S. 166ff.; 


Klettke/Meyer (2003), S. 311 ff. 
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an, die Geschäfts- und Finanzinformationen eingehender XBRL-Instanzen mit 
Hilfe eines Services auf die entsprechende Datenstruktur des IS zu verteilen. 


Anwendungsbezogene Sicht | ‘Anwendungsneutrale Sicht. 
(fachliche Anwendungslogik) {Integrationsmechanismen) 


Frontend- | Benutzer- | unterstützt Portal implementiert | Portal- / CA- 
systeme i| aktivität I: Plattform 


nutzt — 
N headline Workflow- 
> l tiert 

Prozesse || Prozess führt aus | Workflow kenene Management- 
aktivität poii System 


Services | Service- 
' AR verzeichnis 


verweist 


bietet beschreibt auf 


Service- 
schnittstelle 


ist Referenz 
für 


Anwendungs- 
systeme 


Abbildung 33: Erweiterung des SOA-Architekturmodells um die Ebene der Services 


4.4 Zusammenfassung und Würdigung des um XBRL erweiterten SOA- 
Architekturmodells 


Das vorliegende Kapitel fokussierte die Darstellung eines Architekturmodells, 
das sich zur Gestaltung und Ausführung von SOBP einsetzen lässt. In Abschnitt 
4.1 wurde dazu der SOBP-Begriff präzisiert, der dieser Arbeit zugrunde liegt. 
Es wurde erklärt, dass sich ein SOBP dadurch auszeichnet, dass die Aktivitäten 
und Teilprozesse der Kernprozesse Informationsbeschaffung, Berichtserstel- 
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lung, Berichtsdistribution und Berichtsaufnahme in Form von Services realisiert 
werden. Die Services eines SOBP lassen sich als Berichtsservices bzw. Be- 
richtsdienste bezeichnen. SOBP werden mit dem Ziel durchgeführt, die Stö- 
rungsursachen zu minimieren, die die Effizienz und Effektivität des betriebli- 
chen Reportings gefährden.658 

Ausgehend von dem in Abschnitt 3.5 präsentierten Verständnis einer SOA 
wurde in Abschnitt 4.2 ein Ebenenmodell vorgestellt, das mit Blick auf die ak- 
tuellen SOA-Beiträge mehrheitlich vorgeschlagen bzw. eingesetzt wird. Mit 
XBRL ließ sich das Architekturmodell in Abschnitt 4.3 um einen derzeit inten- 
siv diskutierten XML-basierten Standard erweitern, der in dem Architektur- 
modell die Aufgabe hat, die im Rahmen des Berichtswesens zu verarbeitenden 
Geschäfts- und Finanzinformationen semantisch zu beschreiben. 

Die Forschungsbemühungen zur Weiterentwicklung von XBRL waren von 
dem Ziel geprägt, einen Standard zu schaffen, mit denen sich die zu ver- 
arbeitenden Geschäfts- und Finanzinformationen gemäß den Sprach- und Syn- 
taxvorgaben von XML anhand geeigneter und eindeutiger Elemente beschrei- 
ben lassen. Das Ergebnis dieser Anstrengungen mündete in einer Reihe von 
XBRL-Taxonomien, die sich für die Zwecke des internen und externen Be- 
richtswesens nutzen lassen. Aufbauend auf den Begriffsverständnissen thema- 
tisch relevanter Autoren wurde XBRL dabei als frei verfügbarer, plattform- und 
systemunabhängiger (technologieunabhängiger) Open-Source-Kommuni- 
kationsstandard für die automatisierte und softwareunterstützte Erstellung, 
Verbreitung und Auswertung monetärer und nicht monetärer Geschäfts- und Fi- 
nanzinformationen definiert. 

Im Ergebnis ist zu konstatieren, dass das erarbeitete Architekturmodell das 
strukturelle Fundament liefert, um die mit dem Einsatz einer SOA erhofften 
Einsparungspotenziale, die aus der angestrebten hohen Wiederverwendbarkeit 
der Services resultieren, zu realisieren.659 In diesem Zusammenhang sieht das 
Architekturmodell vor, dass sich die hierin eingebundenen Dienste durch den 
Einsatz eines Serviceverzeichnisses auffinden und funktionsorientiert einsetzen 
lassen. Auf diese Weise können die Services von einer beliebigen Nutzerzahl 
mehrfach aufgerufen werden. 

Die Potenziale zur schnellen Anpassbarkeit und höheren Wiederverwend- 
barkeit der Dienste werden dadurch gesteigert, dass durch die Veröffentlichung 
der Serviceschnittstellen nicht nur die Nutzung, sondern auch die Wartung der 
Dienste erleichtert wird. In diesem Zusammenhang wird mit der Einhaltung des 
Abstraktionsprinzips beabsichtigt, eine redundante Erstellung von Berichtsser- 
vices zu vermeiden. Hierzu sind die Metadaten bereits bestehender Dienste über 
die Servicebeschreibungen entsprechend auszuwerten. 


658 Vgl. Abschnitt 2.3. 


659 Vgl. Laartz (2008), S. 72. 
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Festzuhalten ist, dass sowohl die Portal-Technologie als auch der Einsatz ei- 
ner Workflow-Engine eine wichtige Bedeutung bei der Ausführung von SOBP 
aufweisen. Mit Hilfe eines Portals lassen sich einzelne Berichtsservices aufru- 
fen und die zu einem Berichtsprozess verknüpften Dienste ausführen. Zudem 
besteht die Möglichkeit, Berichtsservices zur Verfügung zu stellen, die von un- 
ternehmungsexternen Nutzern aufgerufen werden können. Derartige Services 
könne beispielsweise die Abfrage einzelner Informationen einer Bilanz zum 
Ziel haben. Gleichzeitig haben unternehmungsexterne Anbieter von Services 
die Möglichkeit, ihre Dienste am Portal der SOA-betreibenden Unternehmung 
anzumelden bzw. zu registrieren und damit zur Nutzung freizugeben. 

Die WMS-Komponente ermöglicht, dass die auszuführenden Berichtsprozes- 
se in der korrekten Reihenfolge unter Beachtung aller Vorgaben ablaufen und 
dokumentiert werden. Dadurch lassen sich die Berichtsprozesse transparent ges- 
talten sowie ihre Kontrolle gewährleisten. Darüber hinaus birgt der Einsatz ei- 
ner Workflow-Engine das Potenzial, eine applikations- und/oder unterneh- 
mungsübergreifende SOBP zu flexibilisieren und/oder zu automatisieren. 

Zusätzlich unterstützt das Architekturmodell die kombinierte Verwendung 
von XBRL und Services. Dienste lassen sich in diesem Zusammenhang nutzen, 
um die Geschäfts- und Finanzinformationen, die in den XBRL-Instanzen se- 
mantisch beschrieben sind, aufzunehmen, zu transformieren und das Ergebnis 
der Transformation nachfolgenden Berichtsservices zur Verfügung zu stellen. 
Dadurch, dass Services genutzt werden, die die Daten bestehender Berichtsan- 
wendungen verarbeiten, lassen sich zudem die verschiedenen IS, die für die 
Zwecke des Berichtswesens zum Einsatz kommen, auch weiterhin in einer SOA 
nutzen. Dies bedeutet für die Unternehmungen die Aussicht auf steigende In- 
vestitionssicherheit.660 


660 Vgl. Streibich (2008), S. 74. 
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5 Vorgehensmodell zur konzeptionellen Gestaltung Serviceorien- 
tierter Berichtsprozesse 


Nachdem im vorigen Kapitel ein Architekturmodell für SOBP präsentiert wur- 
de, richtet sich das Erkenntnisziel des vorliegenden Kapitels auf die Frage, wie 
sich SOBP unter Wahrung einer methodischen Vorgehensweise konzeptionell 
gestalten lassen. Festzuhalten ist, dass sich für die methodische Entwicklung ei- 
ner SOA bisher keine einheitliche Vorgehensweise durchsetzen konnte.66! In 
Abschnitt 5.1 werden zunächst bestehende Vorgehensstrategien zur Einführung 
oder Entwicklung einer SOA hinsichtlich ihrer Eignung untersucht, für die kon- 
zeptionelle Gestaltung von SOBP eingesetzt zu werden. Darauf aufbauend wird 
in Abschnitt 5.2 ein Ansatz erarbeitet, der sich zur konzeptionellen Gestaltung 
von SOBP nutzen lässt. Das Kapitel schließt in Abschnitt 5.3 mit einer Zusam- 
menfassung und der kritischen Würdigung des Vorgehensmodells. 


5.1 Evaluation bestehender Vorgehensstrategien zur Gestaltung Service- 
orientierter Anwendungen 


Die Ausführungen dieses Abschnitts stellen die grundsätzlichen Strategien zur 
Gestaltung Serviceorientierter Anwendungen auf Basis einer SOA vor. Prinzi- 
piell kommen für diesen Zweck drei Vorgehensweisen in Frage. Dem Bottom- 
up-Ansatz (Abschnitt 5.1.1) als erste Strategievariante steht der Top-down- 
Ansatz (Abschnitt 5.1.2) gegenüber.662 Als dritte Variante lassen sich die bei- 
den Ansätze zu einer integrierten Vorgehensweise kombinieren, die sich als 
Meet-in-the-middle-Ansatz bezeichnen lässt (Abschnitt 5.1.3). 


5.1.1 Top-down-Ansatz 


Der Top-down-Ansatz zeichnet sich allgemein dadurch aus, dass der spezifische 
Informationsbedarf Ausgangspunkt für die Entwicklung eines IS darstellt.663 
Alle für die Entwicklung relevanten Datenquellen werden nach Bedarf ausge- 
wählt und dem System hinzugefügt. Die grundsätzliche Vorgehensweise bei der 
Top-down-Entwicklung einer SOA ist in Abbildung 34 verdeutlicht. 
Charakteristisch für die Top-down-Vorgehensweise ist, dass Services aus den 
geschäftlichen Anforderungen heraus identifiziert und beschrieben werden.664 


661 Vgl. Beverungen/Knackstedt/Müller (2008), S. 222. 
662 Vgl. Niemann et al. (2002), S. 426. 
663 Vgl. Leser/Naumann (2007), S. 105. 


664 Vgl. Müller (2007b), S. 145. 
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Ausgehend von der Geschäftsstrategie einer Unternehmung wird zunächst die 
IT-Strategie formuliert. Die IT-Strategie gibt vor, welche strategischen Mittel 
der Informationstechnologie zur Umsetzung der Geschäftsstrategie zum Einsatz 
kommen sollen. In diesem Zusammenhang ist über die technologische Plattform 
und damit über die zum Einsatz kommenden Software- und Hardwaresysteme 
zu entscheiden. Darüber hinaus ist die Wahl einer geeigneten Innovationsstrate- 
gie sowie einer Sourcing-Strategie, welche die Verteilung von internem und ex- 
ternem Know-how zum Gegenstand hat, von Bedeutung. Ferner muss eine IT- 
Strategie die Regeln zur Freigabe von IT-Investitionen enthalten. Die Inhalte 
bzw. Vorgaben der IT-Strategie münden in der Definition einer IT-Archi- 
tektur.665 


Geschäfts- 


strategie IT-Strategie 


Prozess- IT- 
Architektur Architektur 


Ablauf- 
organisation 


Entwicklung Betrieb 


Abbildung 34: Top-down-Ansatz zur Einführung einer SOA 


Neben der IT-Strategie und der IT-Architektur ist zur Operationalisierung der 
Geschäftsstrategie die Architektur der Geschäftsprozesse bzw. die Prozess- 
Architektur festzulegen. Eine Prozess-Architektur beschreibt den Gesamtzu- 
sammenhang der Leistungsentwicklung, Leistungserstellung und des Leis- 


665 Zum Begriff der IT-Architektur vgl. 3.1.3.2. 
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tungsvertriebs in einer Organisation.666 Die Prozess-Architektur wirkt sich wie- 
derum auf die Strukturierung der Ablauforganisation der SOA-betreibenden 
Unternehmung aus.66’ Aus Abbildung 34 ist zu erkennen, dass SOA das integ- 
rierende Element zwischen der Prozess- und IT-Architektur darstellt. Als Archi- 
tekturkonzept, das die Prozess- und die IT-Sicht verbindet, ermöglicht eine 
SOA durch einen Top-down-Ansatz, die Logik der Geschäftsprozesse unverän- 
dert in Form von orchestrierten Services zu implementieren.668 

Mit Blick auf die Vorgehensweise zur Gestaltung einer Serviceorientierten 
Anwendung ist festzuhalten, dass beim Top-down-Konzept die Analyse der Ge- 
schäftsprozesse sowie die schrittweise Ableitung von Services im Mittelpunkt 
stehen.669 Der Geschäftsprozessanalyse geht die Erstellung eines Anforde- 
rungskatalogs voraus, in welchem alle wesentlichen Kriterien an das zu entwer- 
fende IS formuliert sind. Idealerweise liegt bereits ein Prozessmodell vor, das 
sich zur fachlichen Gestaltung und Implementierung der Services nutzen lässt. 
Liegt ein Prozessmodell nicht vor, muss es zunächst erstellt werden.670 

Ausgehend von dem zu unterstützenden Geschäftsprozess, d.h. aus einer 
fachlichen Perspektive heraus, werden die entsprechenden Services identifiziert, 
entworfen, implementiert und in ein Verzeichnis eingebunden. Wie aus 
Abbildung 35 hervorgeht, ist es für diesen Zweck erforderlich, die zu unterstüt- 
zenden Geschäftsprozesse schrittweise zu verfeinern und in Module bzw. Teil- 
prozesse aufzuteilen. Die Modularisierung kann in Abhängigkeit von der Kom- 
plexität des Prozesses mehrere Detaillierungsebenen umfassen.67! Die Zerle- 
gung der Geschäftsprozesse ist abgeschlossen, wenn die verfeinerten Prozess- 


666 Vgl. Schelp/Hafner/Winter (2006), S. 214. Mit Hilfe einer Prozess-Architektur lassen 
sich die komplexen Zusammenhänge der Prozesse strukturiert erfassen. Zur Visualisie- 
rung, Analyse und Verbesserung werden die Prozesse in einem Modell mit vernetzten 
Ebenen und unterschiedlichen Detaillierungsstufen abgebildet, wobei jede Ebene der 
Prozess-Architektur unterschiedliche Aspekte und Zielgruppen adressiert. Vgl. Kremar 
(2003), S. 261. 

667 Unter Ablauforganisation wird die räumliche und zeitliche Ordnung von Geschäftspro- 
zessen verstanden, die innerhalb einer Aufbauorganisation vorliegt. Die Aufbauorgani- 
sation einer Unternehmung legt die Zuständigkeiten für die arbeitsteilige Aufgabenerfül- 
lung fest und beschreibt die Organisationseinheiten sowie die zwischen den Organisati- 
onseinheiten existierenden Beziehungen zueinander. Vgl. Oestereich/Weiss (2008), S. 
416f. 

668 Vgl. Liebhart (2007), S. 173. 

669 Vgl. hierzu von Henning (2007), S. 343. 

670 OEHLER bemängelt in diesem Zusammenhang, dass generell in vielen Unternehmungen 
keine umfassenden Prozessdokumentationen vorliegen oder die Prozesse nur unzurei- 
chend dokumentiert sind. Vgl. Oehler (2006), S. 104. 


671 Vgl. Gimnich (2007), S. 72. 
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module eine Granularität erreichen, die der Granularität der Services auf der 
Geschäftsebene entspricht.672 
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Abbildung 35: Vorgehen beim Top-down-Ansatz®73 


Eine wichtige Eigenschaft der Top-down-Vorgehensweise ist, dass gleichartige 
Prozessmodule identifiziert, zusammengefasst und schließlich durch Services 
implementiert werden.674 Diese Konstellation ist in dem in Abbildung 35 be- 
trachteten Beispiel bei den Prozessmodulen M3 und M5 gegeben. Ziel dieses 
Vorgehens ist es, Redundanzen zu vermeiden und eine hohe Wiederverwen- 
dung von Diensten zu erzielen. Die Dienste erfüllen eine abgegrenzte fachliche 
Aufgabe und orientieren sich nicht an den IT-Applikationen, die von der SOA- 
betreibenden Unternehmung genutzt werden,575 sondern an den Aktivitäten der 
auszuführenden Geschäftsprozesse. 


5.1.2 Bottom-up-Ansatz 


Beim Bottom-up-Ansatz erfolgt eine Umkehrung der Teilschritte, die bei der 
Vorgehensweise der Top-down-Strategie durchlaufen werden. In Abgrenzung 
zur Top-down-Strategie steht beim Bottom-up-Ansatz generell die Integration 


672 Vgl. HOB et al. (2007), S. 42. Zum Begriff der Granularität vgl. Abschnitt 5.2.2.1. 
673 In Anlehnung an Höß et al. (2007), S. 43. 
674 Vgl. Höß et al. (2007), S. 43. 


675 Vgl. Müller (2007b), S. 145. 
Alexander Pastwa - 978-3-631-75488-7 


Downloaded from PubFactory at 01/11/2019 04:20:29AM 
via free access 


Vorgehensmodell zur konzeptionellen Gestaltung Serviceorientierter Berichtsprozesse 147 


bestehender und bekannter Datenquellen und Funktionalitäten im Vordergrund, 
die von den IS bereits zur Verfügung gestellt werden.676 Charakteristisch für 
diesen Ansatz ist, dass bei der Gestaltung einer Anwendung mit den Systemtei- 
len auf der untersten Ebene eines hierarchisch gegliederten Systems begonnen 
wird.677 Beim Bottom-up-Ansatz handelt es sich folglich um ein eher technisch 
orientiertes Vorgehen.678 

Mit Blick auf die Gestaltung einer Serviceorientierten Anwendung stellen 
beim Bottom-up-Ansatz nicht die zu unterstützenden Geschäftsprozesse den 
Ausgangspunkt dar. Stattdessen fokussiert diese Vorgehensweise das bestehen- 
de Service- sowie Anwendungssystemportfolio einer Unternehmung.67? 
GIMNICH stellt in diesem Zusammenhang fest, dass sich viele Services aus den 
bestehenden Awendungen gewinnen lassen.680 Der Bottom-up-Ansatz wird 
durch Abbildung 36 verdeutlicht. 


Höherwertige 
Services 


7) 
® 
Se 
e 
® 
mA 
2 
a 
© 
a 


Systeme 


Abbildung 36: Vorgehen beim Bottom-up-Ansatz®8! 


676 Vgl. Leser/Naumann (2007), S. 105; Höß et al. (2007), S. 44. 

677 Vgl. Heinrich (2002), S. 94. 

678 Vgl. Dorda/Steiert/Sellentin (2004), S. 203. 

679 Vgl. Liebhart (2007), S. 173; Müller (2007b), S. 146. 

680 Vgl. Gimnich (2007), S. 68. Zu diesen Services gehören z. B. die Angebotserstellung, 
die Neukundenanlage und die Ermittlung von Konditionen. 

681 In Anlehnung an Höß et al. (2007), S. 44. Im Gegensatz zu der von HÖß ET AL. prasen- 
tierten Abbildung wurden in Abbildung 36 die Pfeile von den IS auf die Services gerich- 
tet. Die dadurch angedeutete Vorgehensweise, aus den IS Services zu gestalten, ent- 


spricht dem Vorgehen nach dem Bottom-up-Ansatz. 
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Wie aus der Abbildung ersichtlich, sind zunächst die von einer Unternehmung 
betriebenen Anwendungssysteme vor dem Hintergrund der Frage zu unter- 
suchen, welche bereits bestehenden Funktionalitäten als potenzielle Services 
implementiert sind.682 Aus diesen Services lassen sich gegebenenfalls neue 
Dienste ableiten, die mit weiteren Services verknüpft werden können, um die 
geforderte Leistung zu erbringen.68 Liegen keine implementierten Services vor, 
empfiehlt es sich, zunächst wichtige Funktionalitäten, die von den bestehenden 
IS erbracht werden, als individuelle Services zu realisieren. Zu diesem 
Zweck werden die bestehenden IS in Anwendungsdomänen zerlegt,685 aus de- 
nen sich entsprechende Services erstellen lassen. Aus diesen Services lassen 
sich gegebenenfalls neue Dienste ableiten, die mit weiteren Services verknüpft 
werden können, um die anvisierten Dienste bereitzustellen.686 Die individuellen 
Services übernehmen in diesem Fall die Aufgabe eines Basisservices für hö- 
herwertige Dienste, die eine wichtige Geschäftsfunktion erbringen.68’ In 
Abbildung 36 ist zu erkennen, dass sich derartige Dienste aus verschiedenen 
Basisservices zusammensetzen. 

Eine Erweiterung des Serviceportfolios erfolgt dann schrittweise. D. h., durch 
die folgenden Schritte sind Services bereitzustellen, welche Funktionen erbrin- 
gen, die von weiteren Applikationen genutzt werden können. In einem vorletz- 
ten Schritt wird geprüft, inwieweit sich einzelne Services gruppieren oder zu ei- 
nem übergeordneten Dienst verknüpfen lassen. Diese Services bieten das Po- 
tenzial, als Aktivitäten eines Serviceorientierten Geschäftsprozesses eingesetzt 
zu werden. In einem letzten Schritt erfolgt bei der Bottom-up-Strategie die Kon- 
figuration der Services zu Serviceorientierten Geschäftsprozessen. 


682 Im Beispiel der Abbildung 36 werden z. B. IS untersucht, die für die Zwecke des CRM 
sowie des ERP genutzt werden. 

683 Vgl. Müller (20076), S. 146. 

684 HÖB ET AL. bemerken in diesem Zusammenhang, dass moderne Systeme beispielsweise 
im ERP-Umfeld über die technische Möglichkeit verfügen, komplette Funktionalitäten 
in einer fachlichen und technischen Form zur Verfügung zu stellen, die einem Service 
im Sinne einer SOA entspricht. Vgl. Höß et al. (2007), S. 44. 

685 Zum Domänenbegriff vgl. Abschnitt 5.2.1.1. Neben der organisatorisch geprägten Aus- 
legung lässt sich der Domanenbegriff auch aus einer informationstechnischen Perspekti- 
ve betrachten. Eine Domäne wird hier verstanden als Gruppierung logisch bzw. fachlich 
zusammengehörender Anwendungen, die jeweils über sich gegenseitig verbindende 
Schnittstellen verfügen müssen. Vgl. Gronau et al. (2008), S. 430 und 434. 

686 Vgl. Müller (2007b), S. 146. 

687 Als Geschäftsfunktion wird eine Aktion aufgefasst, die eine geschäftsrelevante Ande- 


rung zur Folge hat. Vgl. Tilkov/Starke (2007), S. 14. 
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5.1.3 Meet-in-the-middle-Ansatz 


Als drittes Vorgehensmodell zur Entwicklung einer SOA wird nun ein Ansatz 
vorgestellt, der sowohl Eigenschaften des Top-down-Ansatzes als auch Merk- 
male des Bottom-up-Konzeptes aufweist. Bei dieser als Meet-in-the-middle be- 
zeichneten Variante wird eine parallele Vorgehensweise zur Implementierung 
der Dienste angewendet.688 Sowohl die Geschäftsprozesse als auch die Anwen- 
dungssysteme, die zur Ausführung der Geschäftsprozesse zum Einsatz kommen, 
werden analysiert. Folglich sind geeignete Services sowohl auf Basis der vor- 
handenen Anwendungssysteme nach Vorbild des Bottom-up-Ansatzes als auch 
auf Grundlage der Geschäftsprozesse im Sinne des Top-down-Prinzips zu 
erstellen bzw. gegebenenfalls zu modifizieren. 

Abbildung 37 stellt das Vorgehen des Meet-in-the-middle-Ansatzes dar.689 In 
einem ersten Schritt müssen die von der Unternehmung betriebenen IS auf ihre 
Zukunftsfähigkeit analysiert und potenzielle Services identifiziert werden. Der 
zweite Schritt sieht vor, aus den Hauptprozessen Prozessmodule zu bilden, die 
zur Ableitung von höherwertigen Services dienen. In einem dritten Schritt ist zu 
untersuchen, welche höherwertigen Dienste sich durch Basisservices der bereits 
bestehenden IS abbilden lassen. Ist diese Möglichkeit nicht oder nur einge- 
schränkt gegeben, muss entschieden werden, welche Services neu zu entwickeln 
sind. 

Wie in der Abbildung 37 deutlich wird, ist beim Meet-in-the-middle-Ansatz 
die Ebene der höherwertigen Services von Bedeutung, da sich hier sowohl die 
fachliche als auch die IT-Sicht treffen. Auf diese Weise lassen sich die Ge- 
schäftsprozesse einerseits nach fachlichen Aspekten verbessern, andererseits 
können die IS und Services unterhalb der Ebene der höherwertigen Services 
nach IT-orientierten Gesichtspunkten verbessert werden.6% Potenziale ergeben 
sich z. B. dadurch, dass eine gemeinsame Datenhaltung für Kundendaten ver- 
schiedener Geschäftsbereiche durch die IT-orientierte Verbesserung ermöglicht 
wird. 


688 Vgl. Liebhart (2007), S. 174. 
689 Siehe hierzu die Ausführungen von Höß et al. (2007), S. 44f. 


690 Vgl. Höß et al. (2007), S. 45. 
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Abbildung 37: Meet-in-the-middle-Ansatz®?! 


5.1.4 Bewertung der bestehenden Ansätze für die konzeptionelle Gestal- 
tung Serviceorientierter Berichtsprozesse 


Hinsichtlich der praktischen Anwendbarkeit des Top-down- oder Bottom-up- 
Ansatzes zur konzeptionellen Gestaltung eines SOBP ist zu konstatieren, dass 
beide Ansätze in Abhängigkeit der vorliegenden Rahmenbedingungen als ei- 
genständige Konzepte sinnvoll sind. 

Für die Bottom-up-Vorgehensweise spricht, dass auf diese Weise keine Ser- 
vices übersehen werden können,69 die bereits in der Unternehmung realisiert 
wurden und im Hinblick auf das Anwendungsszenario zum Einsatz kommen 


691 In Anlehnung an Höß et al. (2007), S. 44. 


692 Vgl. Gimnich (2007), S. 73. 
Alexander Pastwa - 978-3-631-75488-7 


Downloaded from PubFactory at 01/11/2019 04:20:29AM 
via free access 


Vorgehensmodell zur konzeptionellen Gestaltung Serviceorientierter Berichtsprozesse 151 


können. Eine Begründung für eine Vorgehensweise nach dem Bottom-up- 
Ansatz lässt sich zudem in den Anwendungsfällen identifizieren, bei denen be- 
reits eine Reihe von Anwendungssystemen, in denen große Mengen wertvoller 
und unternehmungskritischer Daten vorliegen bzw. verarbeitet werden, von ei- 
ner Unternehmung betrieben werden.6? Diese Applikationen lassen sich als 
Komponenten einer Serviceorientierten Anwendung verwenden oder erwei- 
tern.69 Mit Blick auf den Anwendungsbereich dieser Arbeit liegt eine derartige 
Situation in einer Unternehmung in der überwiegenden Mehrheit vor, da die 
Geschäfts- und Finanzinformationen, die bei der Ausführung der Berichtspro- 
zesse verarbeitet werden, nicht nur in vielen operativen und analyseorientierten 
IS vorgehalten, sondern auch mit Hilfe diverser Analysetools ausgewertet wer- 
den. 

Da der Bottom-up-Ansatz die „behutsame“ Einführung einer SOA anstrebt, 
sind im Hinblick auf die Amortisation der Anfangsinvestitionen schnellere und 
unmittelbare, kleine Erfolge zu erwarten.69 Darüber hinaus trägt das Bottom- 
up-Prinzip zu einer effektiven Lernphase bei den Mitarbeitern und einem paral- 
lelen Aufbau einer technischen Umgebung, von personellem Know-how und 
organisatorischen Strukturen bei.696 

Im Vergleich zur Top-down-Strategie zeichnet sich der Bottom-up-Ansatz 
zudem durch eine pragmatische Herangehensweise aus. Dies führt allerdings 
zur Gefahr, dass im Ergebnis keine geschlossene Gesamtarchitektur im Sinne 
einer SOA erstellt wird,’ bei der alle Geschäftsprozesse mit Hilfe verknüpfter 
Services ausgeführt werden. Dies ist als Nachteil zu werten, da beim Betrieb ei- 
ner SOA SOBP nur eine von vielen Prozesskategorien darstellen. Infolge der 
fehlenden Prozessorientierung beim Bottom-up-Vorgehen ist ein „Sammelsuri- 
um“ an Berichtsservices zu erwarten, welche je nach Anwendungsbereich bzw. 
Berichtsprozess punktuell entwickelt bzw. eingesetzt werden und nicht die an- 
gestrebte Wiederverwendbarkeit erreichen. Als weiterer Nachteil ist bei der 
Bottom-up-Strategie zu werten, dass der Fokus auf die Daten und die Funktio- 
nalität gelenkt wird, die von den bereits betriebenen Anwendungssystemen vor- 
gehalten bzw. erbracht werden. Eine solch einengende Sicht birgt die Gefahr, 
dass die Nutzen stiftenden Potenziale von domänenübergreifenden Berichtsser- 
vices nicht vollständig erkannt und ausgeschöpft werden. 


693 Vel. Höß et al. (2007), S. 43. SIEBENHAAR ET AL. bemerken in diesem Zusammenhang, 
dass ein Bottom-up-Vorgehen als sinnvoll zu werten ist, da Serviceorientierte Anwen- 
dungen i. d. R. nicht auf der „grünen Wiese“ entwickelt werden. Vgl. Siebenhaar et al. 
(2008), S. 325. 

694 Vgl. Siebenhaar et al. (2008), S. 325. 

695 Vgl. Ernst et al. (2008). 

696 Vgl. Bark/Fritsch (2006). 


697 Vgl. Bark/Fritsch (2006). 
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Im Vergleich zum Bottom-up-Ansatz ist bei der Anwendung der Top-down- 
Strategie der Nachteil zu identifizieren, dass es sich hierbei um eine investiti- 
onsintensivere Vorgehensweise handelt.69 Hohe Aufwendungen entstehen, da 
sämtliche zu unterstützenden Berichtsprozesse modelliert bzw. angepasst wer- 
den müssen. Neben den hohen Anfangskosten ergeben sich zudem sowohl Ge- 
fahren unternehmungskultureller Verwerfungen und Widerstände als auch Tü- 
cken einer zu hastigen und damit unzureichenden Organisation.6% In diesem 
Zusammenhang ist zu bemerken, dass die konsequente Ausrichtung auf die Be- 
richtsprozesse und die damit verbundene „plötzliche“ Umstellung der gesamten 
Arbeitsumgebung in Form einer „Big-Bang“-Lösung zu einer Überforderung 
der Mitarbeiter führen kann. Zu erwarten sind hierdurch weitere Effizienzein- 
bußen. Zu diesem Problemfeld trägt auch das Nichtvorhandensein einer Lern- 
phase bei. Ferner sind durch die erhöhte Komplexität der Abhängigkeiten zwi- 
schen den Berichtsservices verlängerte Gesamtlaufzeiten eines entsprechenden 
Projekts zu erwarten, die sich wie bei anderen SOA-Projekten wiederum auf ei- 
nen niedrigen ROI auswirken. ’% 

Die von BEVERUNGEN/KNACKSTEDT/MÜLLER durchgeführte Gegenüberstel- 
lung verschiedener Ansätze zur Gestaltung einer SOA führt zum Ergebnis, dass 
in der Literatur der Top-down- und der Meet-in-the-middle-Ansatz favorisiert 
werden.’0! Das Vorgehensmodell, das zur Gestaltung eines SOBP zum Einsatz 
kommen soll, muss in jedem Fall berücksichtigen, dass möglicherweise bereits 
Services in der Unternehmung existieren, die sich für die Zwecke des Repor- 
tings nutzen lassen und daher nicht neu implementiert werden müssen. Ebenso 
muss das Vorgehen berücksichtigen, dass in einer Unternehmung typischerwei- 
se bereits verschiedene Berichtsanwendungen genutzt werden, die nicht nur be- 
richtsrelevante Geschäfts- und Finanzinformationen vorhalten, sondern auch 
wiederverwendbare Funktionen in Form von Services zur Verfügung stellen. 

Für ein Top-down-gestütztes Vorgehen spricht, dass mit den in Abschnitt 
2.2.2 identifizierten Kernprozessen vier Prozesskategorien vorliegen, die für die 
Modellierung eines vollständigen Berichtsprozesses als Ausgangspunkt dienen 
können. Damit eröffnet sich der Unternehmung die Möglichkeit, dem Leitge- 
danken einer SOA folgend, die Prozessmodellierung losgelöst von den zugrun- 
de liegenden Anwendungssystemen zu betrachten. Ferner ergibt sich bei diesem 
Vorgehen der Vorteil, dass eine kohärente Umsetzung einer Berichtsstrategie 
ermöglicht wird.’% Wird die konzeptionelle Gestaltung eines SOBP auf Basis 


698 Vgl. Liebhart (2007), S. 173. 

699 Vel. Bark/Fritsch (2006). 

700 Vgl. Ernst et al. (2008). 

701 Vgl. Beverungen/Knackstedt/Müller (2008), S. 222. 

702 LIEBHART spricht in diesem Zusammenhang allgemein von einer Geschäftsstrategie. 


Vgl. Liebhart (2007), S. 173. 
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einer SOA angestrebt, ist mit Blick auf diese Aspekte die Top-down-Strategie 
dem Bottom-up-Ansatz vorzuziehen. 

Um diesen Erwägungen Rechnung zu tragen, wird in dieser Arbeit die Auf- 
fassung vertreten, dass das im Folgenden entwickelte Vorgehensmodell zur 
Gestaltung eines SOBP sowohl den in der Wissenschaft favorisierten Top- 
down-Ansatz als auch den pragmatischen Bottom-up-Ansatz integrieren muss. 
Damit kommt als geeigneter Ansatz der Meet-in-the-middle-Ansatz in Frage.’ 


5.2 Konzeptionelle Gestaltung Serviceorientierter Berichtsprozesse 


Aufbauend auf den vorherigen Ausführungen verfolgt der vorliegende Ab- 
schnitt das Ziel, einen Ansatz zu präsentieren, der sich zur konzeptionellen Ges- 
taltung eines SOBP einsetzen lässt. Dabei repräsentiert die gewählte Gliederung 
bereits die dreistufige Vorgehensweise: Zunächst wird in Abschnitt 5.2.1 die 
Berichtsprozessanalyse aus der Perspektive der Serviceorientierung themati- 
siert. Die berichtsprozessmodellbasierte Serviceidentifikation ist dann Gegens- 
tand des Abschnitts 5.2.2, während die fachliche Gestaltung von Berichts- 
services in Abschnitt 5.2.3 diskutiert wird. 

Mit Blick auf die in Abbildung 34 dargestellte Top-down-Vorgehensweise ist 
in diesem Zusammenhang festzuhalten, dass die folgenden Ausführungen zur 
konzeptionellen Gestaltung eines SOBP nicht die Phasen „Ableitung einer Ge- 
schaftsstrategie“ und „Ableitung einer IT-Strategie“ thematisieren, sondern di- 
rekt bei der Berichtsprozessanalyse ansetzen. Die Phasen „Ableitung einer Ge- 
schaftsstrategie“ und „Ableitung einer IT-Strategie“ werden nicht behandelt, da 
sie Schritte darstellen, die unabhängig von den zu unterstützenden Geschäfts- 
prozessen bei der Entwicklung einer SOA durchzuführen sind. Vor dem Hinter- 
grund der im Rahmen dieser Arbeit untersuchten Fragestellung fokussieren die 
folgenden Ausführungen stattdessen die Phasen „Berichtsprozessanalyse“, „Be- 
richtsserviceidentifikation“ und ,,Berichtsservicespezifikation“ als Kernphasen 
der konzeptionellen Gestaltung eines SOBP. 


5.2.1 Berichtsprozessanalyse aus der Perspektive der Serviceorientierung 


Unter dem Begriff „Berichtsprozessanalyse“ lassen sich alle vorbereitenden und 
unterstützenden Aktivitäten zur Zielbestimmung, Modellierung sowie Anpas- 
sung eines Berichtsprozesses verstehen, die im Vorfeld der Identifikation von 
Berichtsservices durchgeführt werden müssen. In Abschnitt 5.2.1.1 werden Ka- 
tegorien vorgestellt, die sich zur Zielbestimmung des zu gestaltenden SOBP 


703 Damit wird der Auffassung von HÖS ET AL. entsprochen, zwecks einer Erfolg verspre- 
chenden und praxisorientierten Vorgehensweise für die Identifikation und Definition 


von Diensten beide Ansätze in Kombination anzuwenden. Vgl. Höß et al. (2007 S. 45. 
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nutzen lassen. Aspekte der Berichtsprozessmodellierung sowie -anpassung wer- 
den in Abschnitt 5.2.1.2 erörtert. Die Einbindung und Bewertung unterneh- 
mungsexterner Berichtsservices in ein Serviceverzeichnis sowie die Evaluation 
bestehender unternehmungsinterner Berichtsservices ist Gegenstand der Aus- 
führungen von Abschnitt 5.2.1.3. 


5.2.1.1 Zielbestimmung der zu gestaltenden Serviceorientierten Berichts- 
prozesse anhand eines Ordnungsrahmens 


Die Zielbestimmung eines SOBP lässt sich anhand der Dimensionen „Berichts- 
empfänger“, ,, Verantwortlichkeit“, „Strukturierungsgrad des Workflows“, „Aus- 
löser des Reportings“ sowie „Berichtszweck“ durchführen. Einen Überblick 
über die Ausprägungen dieser Dimensionen präsentiert Abbildung 38. 


Dimension Ausprägung 


Verantwortlichkeit | Geschäftszweig | Geschäftseinheit Abteilung Team 


Strukturierungs- Ad-hoc- Semi-strukturierter | Vollständig definierter 
grad Workflow Workflow Workflow 


ee Aktives Reporting Passives Reporting 
Dokumentation von Auslösung von | SEHSASBNERG VER 
Berichtszweck 2% hr | Kontrolle von 
Ereignissen Aktivitäten | 
| Entscheidungen 


Berichts- Operatives Taktisches | Strategisches 
empfänger Management Management Management 


Abbildung 38: Dimensionen zur Zielbestimmung eines SOBP 


Berichtsempfänger 
Vor dem Hintergrund der in dieser Arbeit zugrunde gelegten weiten Auslegung 
des Berichtswesens ist zu konstatieren, dass ein SOBP sowohl auf den Informa- 
tionsbedarf unternehmungsinterner als auch -externer Berichtsempfänger ausge- 
richtet sein kann. Als potenzielle unternehmungsexterne Berichtsempfänger 
kommen sowohl die Stakeholder als auch die Shareholder in Frage.704 

Eine Einteilung der unternehmungsinternen Berichtsempfanger(gruppen) 
lässt sich anhand der Managementebenen durchführen. Zu unterscheiden ist das 


704 Siehe hierzu Abschnitt 2.1.2. 
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operative, taktische und strategische Management. ’05 Manager, die der operati- 
ven Ebene angehören (Lower-Management), sind für ihre Aufgabenerfüllung 
auf historische und/oder aktuelle sowie quantitative Informationen angewie- 
sen.706 Derartige Informationen lassen sich i. d. R. aus den unternehmungsinter- 
nen IS gewinnen. Das strategische Management (Top-Management) fokussiert 
indessen qualitative und aggregierte Informationen. Dabei werden auch unter- 
nehmungsexterne Informationen nachgefragt. Während sich der tendenziell sta- 
bile Informationsbedarf des operativen Managements mit Hilfe eines klassi- 
schen Berichtswesens befriedigen lässt, variiert der Informationsbedarf des stra- 
tegischen Managements stark. Dies ist der Tatsache zu schulden, dass die be- 
reitgestellten Informationen eher sporadisch bzw. unregelmäßig genutzt werden. 
Der Informationsbedarf des taktischen Managements (Middle-Management) 
liegt zwischen den Informationsanforderungen des operativen und strategischen 
Managements. 


Verantwortlichkeit 

Da an einem Berichtsprozess nicht nur verschiedene Personen mit unterschied- 
lichen Verantwortungsbereichen und Aufgaben partizipieren können, sondern 
auch diverse IS genutzt werden, liegt ein weiterer Gestaltungsparameter eines 
SOBP in seiner organisatorischen Reichweite. Mit Blick auf die organisatori- 
sche Reichweite eines SOBP sind die Verantwortlichkeiten für die Berichtsser- 
vices und IS, die bei der Ausführung der SOBP genutzt werden, festzulegen. 
Zur Gruppierung der zum Einsatz kommenden IS und Akteure wird der Domä- 
nenbegriff eingeführt. Eine Domäne steht für eine „natürliche“ Unternehmungs- 
einheit innerhalb der Systemlandschaft mit klaren Verantwortlichkeiten, die in 
der Organisationsstruktur eingebettet ist.70” Als potenzielle Domänen, die in ei- 
nem SOBP für die Berichtserstellung, -verteilung oder den -empfang verant- 
wortlich sein können, kommen z.B. die Leiter eines bestimmten Geschäfts- 
zweigs, einer Geschäftseinheit, einer Abteilung oder eines Teams innerhalb ei- 
ner Unternehmung in Frage. 

Zur Analyse der organisatorischen Reichweite eines SOBP lässt sich ein un- 
ternehmungsinterner von einem unternehmungsübergreifenden SOBP abgren- 
zen. Ein unternehmungsinterner SOBP umfasst alle Informationsflüsse sowie 
Vorgänge zur Verarbeitung der Geschäfts- und Finanzinformationen, die von 
den Domänen innerhalb einer Unternehmung geplant, durchgesetzt und gesteu- 
ert werden. Die Ausrichtung auf die unternehmungsinternen Prozesse, Personen 


705 Vgl. hierzu Gluchowski/Gabriel/Chamoni (1997), S. 73f. 

706 Zu den Aufgaben des operativen, taktischen und strategischen Managements vgl. 
Hellriegel/Jackson/Slocum (1999), S. 11ff.; Gluchowski/Gabriel/Chamoni (1997), S. 9 
und 168ff. 


707 Vgl. Josuttis (2008), S. 135. 
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und IS ist aber nicht gleichbedeutend mit der ausschließlichen Nutzung derarti- 
ger Prozesse für das interne Berichtswesen. In gleichem Maße lässt sich eine 
unternehmungsinterne SOBP auch auf die Produktion von Berichten ausrichten, 
welche den Informationsbedarf unternehmungsexterner Anspruchsgruppen fo- 
kussieren. 

Mit Blick auf den in diesem Abschnitt präsentierten Domänenbegriff wird ei- 
ne unternehmungsinterne SOBP auf einer tieferen Betrachtungsebene in die Ka- 
tegorien geschäftszweiginterne und geschäftszweigübergreifende SOBP einge- 
teilt. Da ein Geschäftszweig aus mehreren Geschäftseinheiten bestehen kann, 
lässt sich auf einer weiteren Detaillierungsstufe ein geschäftseinheitsinterner 
von einem geschäftseinheitsübergreifenden Berichtsprozess unterscheiden. Zur 
weiteren Systematisierung eines geschäftseinheitsinternen SOBP kommt die 
Abgrenzung eines abteilungsinternen gegenüber einem abteilungsübergreifen- 
den SOBP in Frage. Auf der tiefsten Betrachtungsebene ist es denkbar, bei ei- 
nem abteilungsinternen SOBP einen teaminternen von einem teamübergreifen- 
den dienstorientierten Berichtsprozess zu separieren. 

Als besondere Ausprägung eines unternehmungsinternen SOBP lässt sich ein 
konzerninterner dienstorientierter Berichtsprozess anführen. Hierbei handelt es 
sich um einen Berichtsprozess, in dem — je nach Ausprägung der Konzernstruk- 
tur — Domänen partizipieren können, die sowohl zur Konzernmutter als auch zu 
den Konzerntöchtern gehören. 

Im Vergleich zu einem unternehmungsinternen SOBP richtet sich der Ge- 
genstandsbereich eines unternehmungsübergreifenden SOBP auf die Einbin- 
dung von Berichtsservices, die von unternehmungsexternen Domänen bereitge- 
stellt werden. Neben einzelnen Services können auch Teilprozesse, die auf or- 
chestrierten Services basieren, von einer unternehmungsexternen Domäne er- 
bracht und mit den Teilprozessen der berichtenden Unternehmung vernetzt 
werden. Wie bei einer unternehmungsinternen SOBP lassen sich ebenfalls die 
unternehmungsübergreifenden SOBP sowohl für die Zwecke des internen als 
auch externen Reporting gestalten. 


Strukturierungsgrad 

Da SOBP aus mehreren Berichtsservices bestehen, die sich — dem SOA- 
Gedanken folgend — mit Hilfe eines WMS zu einer Serviceorientierten Be- 
richtskette zusammenfügen lassen, ist es möglich, vollständige Berichtsprozesse 
sowie Teilprozesse in unterschiedlicher Art und Weise zu automatisieren. Mit 
Blick auf den Automatisierungsgrad von Workflows lassen sich hierbei die 
Ausprägungen Ad-hoc-Workflow, Semi-strukturierter Workflow sowie voll- 
ständig definierter Workflow unterscheiden. 708 


708 Vgl. Nastansky/Huth (2006), S. 532ff. 
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Vollständig definierte Workflows zeichnen sich durch den höchsten Auto- 
matisierungsgrad aus, da sie eine hohe Wiederholungsfrequenz aufweisen. Al- 
ternativ wird für diese Workflowkategorie der Terminus Production-Workflow 
verwendet. Semi-strukturierte Workflows, die auch als administrative Work- 
flows bezeichnet werden, haben eine niedrigere Wiederholungsfrequenz. Im 
Vergleich zu den vollständig definierten Workflows sind semi-strukturierte 
Workflows weniger komplex und haben eine geringe Zahl von Workflow- 
beteiligten. Charakteristisch für Ad-hoc-Workflows ist, dass sie lediglich ein- 
mal ausgeführt werden. Von allen Workflowtypen haben sie die geringste Wie- 
derholungsfrequenz. I. d. R. entstehen Ad-hoc-Workflows im Rahmen der tägli- 
chen Arbeit. Sie sind folglich typischerweise nicht vollständig planbar. In Ab- 
grenzung zu den erst genannten Prozessen werden Ad-hoc-Workflows daher 
auch als schwach strukturierte Prozesse bezeichnet. 


Auslöser des Reportings 

Ferner muss festgelegt werden, ob der SOBP nach dem Vorbild einer aktiven 
oder passiven Informationsversorgung ausgeführt werden soll. In diesem Zu- 
sammenhang ist zu bestimmen, ob der jeweils betrachtete SOBP für ein Stan- 
dard- oder Ad-hoc-Reporting zur Anwendung kommen soll. Während sich zur 
Erfüllung des Berichtszwecks „Dokumentation von Ereignissen“ ein Standard- 
Reporting eignet, lässt sich der Berichtszweck „Auslösung von Aktivitäten“ mit 
Hilfe eines Ad-hoc-Reportings realisieren. Zur Vorbereitung und Kontrolle von 
Entscheidungen lassen sich beide Reporting-Konzepte nutzen. 


Berichtszweck 

Das letzte Kriterium zur Unterscheidung eines SOBP orientiert sich an den Be- 
richtszwecken, die mit den zu gestaltenden Berichtsprozessen verfolgt werden. 
Mit Blick auf die Ausführungen in Abschnitt 2.1.3 lassen sich hierzu sowohl 
unternehmungsinterne als auch -externe SOBP zur Dokumentation von Ereig- 
nissen, Auslösung von Aktivitäten sowie Vorbereitung und Kontrolle von Ent- 
scheidungen einsetzen. 


5.2.1.2 Modellierungsmethodengestützte Erstellung neuer Berichtspro- 
zesse oder Veränderung bestehender Berichtsprozesse 


Bevor die Identifikation sowie die fachliche Gestaltung der Berichtsservices 
beginnt, muss sichergestellt werden, dass ein Berichtsprozess auch tatsächlich 
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vorliegt.’09 Liegt kein Berichtsprozess vor, so muss ein solcher erstellt werden. 
Existiert bereits ein Berichtsprozess, ist zu prüfen, inwieweit sich dieser für die 
weitere Betrachtung eignet oder zu überarbeiten ist. 


5.2.1.2.1 Vorgehen 


Damit aus einem Berichtsprozess geeignete Berichtsservices, die sich zu einem 
SOBP verknüpfen lassen, abgeleitet werden können, muss der zu gestaltende 
Berichtsprozess systematisch solange in Teilprozesse zerlegt werden, bis eine 
weitere Aufspaltung der Teilprozesse aus funktioneller Sicht nicht mehr sinn- 
voll ist. Die elementaren Teilprozesse bzw. die in ihnen enthaltenen Basisaktivi- 
täten dienen im Anschluss als Ausgangspunkt für die Identifizierung der Be- 
richtsservices. Als Startpunkt zur Zerlegung des Berichtsprozesses lassen sich 
die Prozesse Informationsbeschaffung, Berichtserstellung, Berichtsdistribution 
und Berichtsaufnahme heranziehen. Diese stellen die Kernprozesse des Be- 
richtswesens dar und wurden in Abschnitt 2.2.2 erörtert. 

Exemplarisch wird in Abbildung 39 die schrittweise Verfeinerung des Kern- 
prozesses der Informationsbeschaffung des Berichtswesens dargestellt. Den 
Anwendungshintergrund des gewählten Beispiels stellt die Erstellung eines Be- 
richts dar, der am Monatsende die wichtigsten Kennzahlen zur Performance der 
Konzerntöchter beinhaltet. Die Bereitstellung dieser Informationen erfolgt unter 
Einsatz eines DWH-gestützten Berichtssystems.7!0 

In Abbildung 39 ist ersichtlich, dass sich der Kernprozess der Informations- 
beschaffung auf der zweiten Prozessebene in die Teilprozesse der Informations- 
identifikation und Informationsaufbereitung gliedert. Während die Informati- 
onsidentifikation darauf ausgerichtet ist, sämtliche im Hinblick auf die Be- 
richtsanforderungen erforderlichen Informationsquellen und die von diesen je- 
weils vorgehaltenen Informationen zu bestimmen, fokussiert die Informations- 
aufbereitung alle Verarbeitungsanweisungen, welche die identifizierten Infor- 
mationen in einen auswertbaren Zustand versetzen. 

Da in dem hier betrachteten Anwendungsfall eine DWH-Anwendung für das 
Reporting zum Einsatz kommen soll, lässt sich der Prozess der Informations- 
aufbereitung in die Teilprozesse Extraktion, Transformation und Laden aufspal- 
ten.’!! Der Teilprozess der Extraktion sorgt für die Selektion und Bereitstellung 
der Quelldaten, die für die Kennzahlenermittlung verwendet werden. Da diese 


709 MULLER führt in diesem Zusammenhang aus, dass eine Geschäftsprozessanalyse immer 
einen Geschäftsprozess voraussetzt. Vgl. Müller (2007b), S. 149. Darüber hinaus stellt 
der Autor fest, dass neben der Serviceidentifikation die Analyse und Beschreibung der 
Informationen und Informationsflüsse für die Gestaltung von Services von wesentlicher 
Bedeutung ist. Vgl. Müller (2007b), S. 145. 

710 Siehe hierzu die Ausführungen in Abschnitt 2.2.1.1. 


711 Zum ETL-Prozess vgl. die Ausführungen in Abschnitt 2.2.1.1. 
Alexander Pastwa - 978-3-631-75488-7 


Downloaded from PubFactory at 01/11/2019 04:20:29AM 
via free access 


Vorgehensmodell zur konzeptionellen Gestaltung Serviceorientierter Berichtsprozesse 159 


Daten typischerweise in heterogener Form und in verschiedenen Vorsystemen 
vorliegen, ist sicherzustellen, dass sie aus den identifizierten Quellen vollstän- 
dig extrahiert und allen relevanten weiteren Teilprozessen zugeführt werden. 


. Prozess- Berichts- Berichts- Berichts- 
ebene beschaffung erstellung distribution aufnahme 


. Prozess- Informations- 
ebene i i aufbereitung 


. Prozess- 


shen ransformatio 


. Prozess- Filterun Harmoni- 
ebene g sierung 


Aggregation Anreicherung 


. Prozess- 
ebene 


Abbildung 39: Exemplarische Zerlegung des Berichtsprozesses Informationsbe- 
schaffung 


Der Teilprozess der Transformation fokussiert die Umwandlung der Quelldaten 
in das DWH-Zielformat. Als weitere Teilprozesse lassen sich die Filterung, 
Harmonisierung, Aggregation und Anreicherung identifizieren. Die Filterung 
der Daten gewährleistet, dass nur die für die Berichtserstellung sowie für eine 
eventuelle multidimensionale Analyse notwendigen Daten in das DWH des Be- 
richtssystems gelangen. Der sich hieran anschließende Teilprozess der Harmo- 
nisierung befreit die Daten von syntaktischen und semantischen Mängeln. Zu- 
dem werden Kodierungen, Synonyme und Homonyme aufeinander abgestimmt 
sowie unterschiedliche Begriffsabgrenzungen vereinheitlicht. Der darauf einset- 
zende Teilprozess der Transformation hat zum Ziel, den nun konsistenten, aber 
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in der niedrigsten Granularitätsstufe vorliegenden Datenbestand in Bezug auf 
individuell festzulegende Kriterien zu aggregieren, um eine Leistungssteigerung 
der nachfolgenden Analyse zu bewirken. Die Anreicherung schließt den Trans- 
formationsprozess ab. Hier findet eine Erweiterung der Daten um funktionale 
Aspekte statt, indem beispielsweise Berechnungen durchgeführt werden, die für 
die spätere Berichtserstellung notwendig sind. 

Beim Ladeprozess, der dem Transformationsprozess folgt, werden die extra- 
hierten und transformierten Daten in das DWH geladen und für eine spätere 
Nutzung dauerhaft abgelegt.7!2 Wie in der Abbildung 39 zu erkennen ist, lassen 
sich die bestehenden Teilprozesse auf einer tieferen Ebene in weiteren Teilpro- 
zessen verfeinern. In diesem Zusammenhang muss entschieden werden, inwie- 
weit eine weitere Zerlegung eines Teilprozesses fachlich sinnvoll ist. 


5.2.1.2.2 Einsatz von Modellierungsmethoden 


Für die strukturierte Darstellung der Prozessbeschreibungen sind geeignete 
Modellierungsmethoden einzusetzen.’!3 Dabei lassen sich zur Modellierung 
von Prozessen grafische Werkzeuge mit einer spezifischen Modellunterstützung 
verwenden.’!4 Angestrebt wird eine Standardisierung von Prozessen mit Hilfe 
grafischer Objekte, die von der jeweiligen Modellierungssprache zur Verfügung 
gestellt werden. Im deutschsprachigen Raum hat sich zur Konstruktion von Ge- 
schäftsprozessmodellen auf fachkonzeptioneller Ebene aufgrund ihres Anwen- 
dungsbezugs und einer umfassenden Tool-Unterstützung die ereignisgesteuerte 
Prozesskette (EPK) durchgesetzt.7!5 Als Modellierungskonzept hat sich die 
EPK sowohl in der Wissenschaft als auch in der Praxis etabliert. 716 


712 Um eine zeitnahe Bereitstellung der Daten zu gewährleisten, ist dabei der Frage nachzu- 
gehen, in welchen Zeitintervallen die Daten in das DWH geladen werden müssen, um 
eine ausreichende Aktualität und Qualität zu ermöglichen. Diese Entscheidung ist vor 
dem Hintergrund der zur Verfügung stehenden Hardwareausstattung und eingesetzten 
Software zu treffen. Generell muss in diesem Zusammenhang abgewägt werden zwi- 
schen der gewünschten Qualität und Dauer einer Datenanalyse bzw. Berichtserstellung 
sowie den für die Aufbereitung der multidimensional modellierten Daten benötigten 
Systemressourcen. Ziel sollte es sein, ein adäquates Verhältnis von Leistungseinbußen 
und Erkenntnisgewinn zu gewährleisten. 

713 Vgl. Beverungen/Knackstedt/Müller (2008), S. 223. 

714 Vgl. Oehler (2006), S. 104. 

715 Vgl. Nüttgens/Rump (2002), S. 64. Zur Prozessmodellierung lassen sich auch die Uni- 
fied Modeling Language (UML) oder Petri-Netze einsetzen. Daneben ist auch der Ein- 
satz von Aktivitätsdiagrammen möglich. Zur Klassifizierung verschiedener Methoden 
der Prozessmodellierung vgl. Gehring/Gadatsch (1999), S. 10f.; Specht/Weisbecker/ 
Spath (2006), S. 11. 


716 Vgl. Seidlmeier/Scherfler (2007), S. 95. 
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Mit einer EPK lässt sich der Ablauf eines Geschäftsprozesses logisch und 
zeitlich beschreiben.’!7 Die EPK-Darstellung ist ein bipartiter gerichteter 
Graph, in dem sich zwei Mengen von Knoten abwechseln: Ereignisse und 
Funktionen. Auf diese Weise wird eine logische 1:1-Zuordnung erreicht, die 
ausdrückt, welches Ereignis als Eingabe von welcher Funktion behandelt wer- 
den soll und welches Ereignis als Ausgabe einer Funktion entsteht. Die Ver- 
knüpfungslinien zwischen den Knoten sind gerichtet, da die Funktionen nach 
den Ereignissen ausgeführt werden bzw. die nächsten Ereignisse nach den 
Funktionen entstehen. Somit entsteht eine zeitliche und alternierende Abfolge 
von Ereignissen und Funktionen. 

Die EPK bietet die Syntaxregeln UND, ODER und EXKLUSIV-ODER zur 
Verknüpfung und Verzweigung an. Vor einer Funktion lassen sich Ereignisse 
verknüpfen, die eine Bedingung zur Ausführung der nächsten Funktion darstel- 
len, die selber wiederum mehrere Ereignisse erzeugen kann. Ebenso kann ein 
Ereignis zur Verzweigung in mehrere Funktionen führen, deren Ergebnisse 
wiederum zu einem Ereignis verbunden werden. Schließlich gibt es zur Partiti- 
onierung des Graphen zudem einen Prozesswegweiser, der mehrere Elemente 
zusammenfasst. Der Prozesswegweiser kann geöffnet werden, um die darin ent- 
haltenen Schritte anzuzeigen. 

Die ursprünglichen Möglichkeiten der EPK lassen sich um Elemente erwei- 
tern, mit denen den Funktionen auch die Organisationseinheiten, in denen die 
Prozesse ausgeführt werden, sowie die von der Ausführung betroffenen Doku- 
mente zugeordnet werden. Diese und andere Elemente sowie weitere Regeln, 
wie z.B. solche zur Darstellung von Schleifen, sind in der erweiterten EPK 
(eEPK) enthalten.’7!8 Aktuelle Ansätze versuchen, die Ausführung von Funktio- 
nen durch Services in der Modellbeschreibung zu berücksichtigen.’!9 Dafür 
werden weitere Elemente zur Beschreibung von Services (synchron, asynchron) 
und Ausnahmen-Ereignisse (Timeout, Nachricht nicht erhalten) unter dem Titel 
serviceorientierte EPK (sEPK) eingeführt, die sich in die Graphen aus den be- 
kannten Elementen nahtlos integrieren lassen. 


5.2.1.3 Einbindung einer Lebenszyklusbetrachtung der Berichtsservices 
als übergeordneter Prozess 


Für die Gestaltung eines SOBP reicht die Anwendung einer geeigneten Metho- 
dik, mit der die Realisation der geforderten Funktionalität durch den zu kon- 


717? Baumgartner/Ebert/Schleider (o. J.), S. 5. 
718 Vgl. Scheer/Thomas (2005), S. 1069ff. 


719 Vgl. Huth/Wieland (2008), S. 6. 
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zipierenden Berichtsservice angestrebt wird, allein allerdings nicht aus.’20 
Gleichzeitig muss sichergestellt werden, dass die Qualität der eingesetzten Be- 
richtsservices das Mindestmaß erreicht, das von der SOA-betreibenden Unter- 
nehmung vorgegeben ist. Wird dem Grundgedanken einer SOA gefolgt, appli- 
kations- und/oder unternehmungsübergreifende Geschäftsprozesse mittels ver- 
knüpfter Dienste effizient auszuführen, so muss die Nutzung der Berichtsservi- 
ces über deren gesamte „Lebensdauer“ mit Hilfe geeigneter betriebswirtschaft- 
licher Instrumente begleitet werden. Dies betrifft auch unternehmungsexterne 
Berichtsservices, die in einem SOBP eingebunden werden sollen. Die Betrach- 
tung der Lebensdauer eines Berichtsservices ist von Bedeutung, da sich Be- 
richtsprozesse beispielsweise im Zuge neuer gesetzlicher Anforderungen oder 
einer Veränderung der Konzernstruktur verändern. Werden zudem unterneh- 
mungsexterne Berichtsservices eingesetzt, um beispielsweise Währungen umzu- 
rechnen oder Aktienkurse zu aktualisieren, erscheint die Bewertung der Qualität 
der Services umso wichtiger. 

Als geeigneter Ansatz lässt sich für diese Zwecke eine Lebenszyklusbetrach- 
tung durchführen. Eine solche Betrachtung wird im aktuellen Abschnitt ange- 
strebt. Die Ausführungen stützen sich auf einen Beitrag von BERBNER ET AL.,?2! 
in welchem die Autoren zur Durchführung einer Lebenszyklusbetrachtung von 
Web Services acht Phasen von einander abgrenzen.’22 Diese sind in Abbildung 
40 verdeutlicht. 


720 Die Designprinzipien der Serviceorientierung stellen in diesem Zusammenhang die 
zentralen Konzepte für die Einbindung der Services in ein Verzeichnis, für die Orches- 
trierung sowie Nutzung der Dienste dar. 

721 Vgl. Berbner et al. (2005), S. 269ff. 

722 Ein Phasenmodell zur Lebenszyklusbetrachtung findet sich unter anderem auch bei 
Burghardt (2004), S. 18f. Da die Lebenszyklusbetrachtung bei BERBNER ET AL. detail- 


lierter ist, wird diesem Modell der Vorzug gegeben. 
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Abbildung 40: Lebenszyklus eines Berichtsservices 


1. Phase: Anmeldung am Portal des Nutzers 

Die erste Phase des Lebenszyklus eines Berichtsservices betrifft nur diejenigen 
Dienste, die von einem unternehmungsexternen Anbieter zur Verfügung gestellt 
werden. Bevor ein unternehmungsexterner Berichtsservice genutzt werden 
kann, muss der betreffende Service von den potenziellen Nutzern begutachtet 
und zur Nutzung freigegeben werden. Hierfür ist es notwendig, dass sich der 
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Anbieter des Dienstes zunächst am Portal des Nutzers registriert.723 Bei der Re- 
gistrierung sind alle erforderlichen Informationen zur Kontaktaufnahme wie 
Anschrift oder Ansprechpartner anzugeben. Im Anschluss hat der Service- 
Provider die Möglichkeit, den von ihm angebotenen Berichtsservice am Portal 
des Nutzers anzumelden. Eine Anmeldung gilt als abgeschlossen, wenn der 
Service-Provider verbindlich alle Dienstgüteeigenschaften in Form eines Servi- 
ce Level Agreements (SLA) zu dem von ihm angebotenen Dienst zur Verfü- 
gung stellt.724 


2. Phase: Evaluierung der Dienstgüte 

Nachdem der Berichtsservice mit zugehörigem SLA am Portal angemeldet wur- 
de, ist im zweiten Schritt über die Qualität des angebotenen Services zu ent- 
scheiden. Die Bewertung der in Frage kommenden Services wird von den po- 
tenziellen Nutzern durchgeführt. Die Evaluation der Dienstgüte der Berichts- 
services ist erforderlich, damit die angebotenen Dienste verschiedener Provider 
auf Basis ihrer Dienstgüteeigenschaften miteinander verglichen werden können. 
Mit Hilfe von Gewichtungsfaktoren lassen sich Präferenzen und einsatzspezifi- 
sche Besonderheiten bei der Bewertung der Berichtsservices berücksichtigen. In 
gleicher Weise ist mit allen Services zu verfahren, die eigenentwickelt werden 
und dem Serviceportfolio zugeführt werden sollen. 


3. Phase: Vorselektion 

Die Phase der Vorselektion wird mit dem Ziel durchgeführt, auf Basis der Er- 
gebnisse der zweiten Phase mit Hilfe von Ausschlussregeln zu entscheiden, 
welche Berichtsservices in das interne Verzeichnis aufgenommen werden. 
Grundsätzlich lassen sich drei Varianten einer Ausschlussregel definieren. Bei 
der ersten Variante werden alle Kriterien eines Dienstes bei der Definition einer 
Ausschlussregel einbezogen. In diesem Fall ist es möglich, Schwellenwerte 
vorzugeben, die ein Berichtsdienst erfüllen muss, um in das interne Servicever- 
zeichnis der SOA-betreibenden Unternehmung aufgenommen zu werden. 

Im Unterschied zur ersten Variante setzt sich eine Ausschlussregel bei der 
zweiten Variante nur aus ausgewählten Kriterien zusammen. Schwellenwerte 
lassen sich wie bei der ersten Variante ebenfalls einsetzen, um eine Ausschluss- 
regel zu definieren. Eine Verknüpfung der Teilkriterien ist ebenfalls möglich. 


723 An dieser Stelle wird angenommen, dass der Bereitschaft des Service-Providers, einen 
Dienst anzumelden, eine Anbahnungsphase vorausgegangen ist. Ein Service-Provider 
kann beispielsweise infolge einer öffentlichen Ausschreibung seinen Berichtsservice 
anbieten. Alternativ ist der Fall denkbar, dass die SOA-betreibende Unternehmung ih- 
rerseits aktiv in öffentlichen Verzeichnissen nach geeigneten Diensten sucht und die 
betreffenden Anbieter zur Anmeldung ihrer Services einlädt. 


724 Zum Begriff des SLA vgl. Abschnitt 5.2.3.4. 
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Darüber hinaus lässt sich neben einer absoluten Bewertung der Berichtsservices 
auch eine relative Betrachtung durchführen. Die letzte Bewertungsvariante liegt 
z. B. vor, wenn nur Dienste selektiert werden dürfen, die sich unter den zehn 
„besten“ Services befinden. 

Als dritte Variante lassen sich Berichtsservices unabhängig von einer quanti- 
tativen Bewertung ausschließen. Ein solcher Fall ist gegeben, wenn die SOA- 
betreibende Unternehmung beispielsweise aus strategischen Erwägungen 
grundsätzlich nicht bereit ist, Dienste von einem bestimmten externen Provider 
zu verwenden. 

Die unternehmungsinternen und -externen Provider der nicht berücksichtig- 
ten Berichtsservices können über Gründe für die Ablehnung benachrichtigt 
werden.’25 Die unternehmungsexternen Provider haben im Anschluss die Mög- 
lichkeit, die Qualität des von ihnen angebotenen Services zu verbessern und den 
Dienst erneut am Portal anzumelden. Wird hingegen ein unternehmungsinterner 
Dienst abgelehnt, so besteht auch hier die Möglichkeit, Anpassungen an dem 
betreffenden Service vorzunehmen, um die Dienstgüte zu steigern. 


4. Phase: Integration in das interne Verzeichnis 

Die Aufnahme eines Berichtsservices in das interne Verzeichnis erfolgt bei al- 
len Diensten, die vorselektiert wurden (3. Phase). Nach der Einbindung der Ser- 
vices in das interne Verzeichnis stehen die Dienste zur Nutzung zur Verfü- 
gung. ’26 Hier wird der Fall eintreten, dass einige Berichtsservices im Laufe ih- 
rer Lebensdauer nicht oder nur selten ausgeführt werden, so dass nach einiger 
Zeit diese Services deaktiviert werden können (8. Phase). 


5. Phase: Anpassung der Ausschlussregeln 

In den Ausführungen zur zweiten und dritten Phase wurde deutlich, dass dieje- 
nigen Services zur Anwendung kommen sollten, deren Dienstgüteeigenschaften 
im Vergleich zu konkurrierenden Serviceangeboten gleich sind oder diese über- 
treffen. Bei der Selektion eines Berichtsservices zur Laufzeit lassen sich ergän- 
zend zu den bereits vorhandenen Ausschlussregeln weitere Nebenbedingungen 
definieren, die bei der Aufnahme eines Dienstes in das Verzeichnis zu berück- 
sichtigen sind. Der Einsatz solcher Nebenbedingungen hängt von den Anforde- 
rungen sowie der Bedeutung des auszuführenden Berichtsprozesses ab. Ist ab- 
zusehen, dass ein Berichtsservice besonders häufig ausgeführt werden muss, 


725 Ebenso können die Serviceanbieter informiert werden, wenn der Dienst nach einer ge- 
wissen Nutzungszeit aus dem Verzeichnis genommen wird. Vgl. Burghardt (2004), S. 
19. 

726 Die Integration der Services in das Verzeichnis der SOA-betreibenden Unternehmung 


wird auch als Deployment bezeichnet. Vgl. hierzu Burghardt (2004), S. 18. 
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lassen sich an diesen Service weitere bzw. höhere Anforderungen definieren, 
die erfüllt sein müssen, damit der jeweilige Dienst zum Einsatz kommt.727 


6. Phase: Ausführung 

Nachdem die Dienstgüte des jeweiligen Berichtsservices die erforderlichen Kri- 
terien erfüllt hat und der Dienst in das interne Verzeichnis integriert wurde, 
steht der betreffende Service zur Nutzung zur Verfügung. Die Berichtsservices 
werden dynamisch zur Laufzeit zu einem SOBP gekoppelt und ausgeführt. In- 
nerhalb des Lebenszyklus eines Berichtsservices nimmt die Phase der Ausfüh- 
rung die längste Zeit ein. 


7. Phase: Accounting 
Das Ziel dieser Phase ist die verursachungsgerechte Zurechnung der Nutzung 
eines Berichtsservices. Sowohl für den Serviceanbieter als auch für den 
-nachfrager ist die Be- und Zurechnung der Serviceausführung von Bedeutung. 
Kommen Berichtsservices zum Einsatz, die von einem unternehmungsexternen 
Provider gegen Entgelt bereitgestellt werden, ist Sorge zu tragen, dass die fälli- 
gen Gebühren für die Inanspruchnahme des Services an den Anbieter fristge- 
recht entrichtet werden. Den Servicenehmer unterstützt das Accounting bei der 
verursachungsgerechten Zuordnung der für die Inanspruchnahme der Berichts- 
services anfallenden Kosten. Die Kosten sind den internen Organisationseinhei- 
ten zuzurechnen, welche die betreffenden Dienste nutzen. 

In der Phase des Accounting ist ferner darüber zu entscheiden, ob der betref- 
fende Berichtsservice weiterhin genutzt oder aus dem Servicebestand entfernt 
werden soll. 


8. Phase: Deaktivierung 

Die Phase der Servicedeaktivierung bildet den Abschluss des Lebenszyklus ei- 
nes Berichtsservices. Ein Berichtsservice muss deaktiviert werden, wenn die 
von ihm bereitgestellte Funktionalität nicht mehr benötigt wird. In diesem Fall 
ist der betreffende Dienst aus dem internen Verzeichnis zu entfernen. Ein weite- 
rer Grund für die Deaktivierung eines Berichtsservices ist gegeben, wenn der 
Anbieter des Dienstes den entsprechenden Service nicht mehr zur Nutzung zur 
Verfügung stellen kann oder möchte. 


727 Derartige Anforderungen betreffen z. B. alle in Abschnitt 5.2.3.4.1 erläuterten techni- 


schen Dienstgüteeigenschaften. 
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5.2.2 Prozessmodellbasierte Serviceidentifikation 


Bevor Berichtsservices fachlich gestaltet und zu einem SOBP verknüpft werden 
können, ist es notwendig, die potenziellen Services aus einem Prozessmodell 
heraus zu identifizieren.’28 In diesem Zusammenhang ist zu konstatieren, dass 
sich bisher kein einheitliches methodisches Vorgehen zur Serviceidentifikation 
durchgesetzt hat.’29 Das Ziel der nachfolgenden Ausführungen richtet sich da- 
her darauf, eine geeignete Methodik zu entwickeln, die sich zur Identifikation 
von Berichtsservices einsetzen lässt. 

In Abschnitt 5.2.2.1 wird zunächst die Bedeutung der Wiederverwendung 
von Services beleuchtet. Die Wiederverwendbarkeit von Services ist das zentra- 
le Ziel der Serviceidentifikation. In diesem Zusammenhang wird der Begriff der 
Granularität eingeführt, der für die weiteren Ausführungen von besonderer Re- 
levanz ist. Da das in dieser Arbeit konzipierte Vorgehensmodell dem Meet-in- 
the-middle-Ansatz entspricht, 730 ist zu bemerken, dass bei der Serviceidentifika- 
tion die Top-down- und Bottom-up-gestützte Herangehensweise kombiniert und 
integrativ zum Einsatz kommen. Vor diesem Hintergrund widmet sich Ab- 
schnitt 5.2.2.2 zunächst der Top-down-gestützten Serviceidentifikation, wäh- 
rend in Abschnitt 5.2.2.3 die Bottom-up-gestützte Herangehensweise im Vor- 
dergrund steht. 


5.2.2.1 Wiederverwendung als Ziel der prozessmodellbasierten Service- 
identifikation 


Die Modellierung des gesamten Berichtsprozesses hat zum Ziel, Berichtsservi- 
ces zu identifizieren, die sich durch einen hohen Wiederverwendungsgrad aus- 
zeichnen. Dabei wird ein Service als wiederverwendbar bezeichnet, wenn er 
sich nicht nur innerhalb eines Anwendungsgebiets, sondern auch über Fachbe- 
reichsgrenzen hinweg für verschiedene Problemstellungen sowie in einer Viel- 
zahl von heterogenen Anwendungen nutzen lässt.’3! Mit der Wiederverwend- 
barkeit von Diensten wird ein Ziel verfolgt, das generell an Serviceorientierte 
Anwendungen gerichtet ist. Mit Blick auf die Gestaltung und Ausführung eines 
SOBP liegt eine hohe Wiederverwendbarkeit eines Berichtsservices dann vor, 
wenn der Dienst in verschiedenen SOBP einsetzbar ist.732 


728 Auf die generelle Bedeutung, bei der Konzeption einer SOA ein wichtiges Augenmerk 
auf die Identifikation der Services bzw. Strukturierung der Gesamtfunktionalität einer 
Anwendung in wohldefinierte Dienste zu legen, verweisen auch HOB ET AL. und KLOSE/ 
KNACKSTEDT. Vgl. Höß et al. (2007), S. 40; Klose/Knackstedt (2007), S. 47. 

729 Vgl. Klose/Knackstedt (2007), S. 47; Müller (2007b), S. 145. 

730 Vgl. hierzu die Ausführungen in Abschnitt 5.1.4 

731 Vgl. Gimnich (2007), S. 68; Winkler (2007), S. 258. 


732 Vgl. Winkler (2007), S. 258. 
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Die Wiederverwendung von Services ist von Bedeutung, da sich auf diese 
Weise signifikante Einsparpotenziale für die SOA-betreibende Unternehmung 
ergeben. Das Einsparpotenzial, das aus der Wiederverwendung vorhandener 
Software resultiert, beläuft sich nach der Einschätzung von BALZERT beispiels- 
weise auf % der Entwicklungszeit sowie der dafür eingesetzten Ressourcen. 733 
Ein wichtiger Faktor für die Wiederverwendbarkeit eines Services ist seine 
Granularität. Die Granularität steht für den Umfang und die Art der Funktionen, 
die durch einen Service ausgeführt werden.734 Services mit einer hohen Granu- 
larität verarbeiten eine Vielzahl von Datenobjekten sowie vereinen verschiede- 
ne Aktionen, die sequenziell ausgeführt werden. Demgegenüber führen Dienste 
mit einer niedrigen Granularität nur einzelne oder wenige Aktionen aus. 

Die Bedeutung der Servicegranularität lässt sich anhand der Auswirkungen 
verdeutlichen, die sich einstellen, wenn Services nicht in der geforderten Granu- 
larität bereitgestellt werden. Werden Berichtsdienste mit geringer Granularität 
eingesetzt, ist das Ergebnis eine große Anzahl von Services. Dies hat zur Folge, 
dass die Verwaltung der Dienste erschwert sowie die Suche nach dem richtigen 
Service aufwendiger wird. Werden hingegen Reportingservices mit einer gro- 
ben Granularität bevorzugt, besteht die Gefahr, dass die Dienste aufgrund ihres 
(zu) groben Funktionsumfangs nicht die Fähigkeit besitzen, in anderen Be- 
richtsprozessen eingesetzt zu werden. Der Vorteil einer Wiederverwendung und 
die sich daraus ergebenden Potenziale zur Flexibilisierung der Geschäftsprozes- 
se werden im Fall grobgranularer Services demzufolge gemindert.735 

Um Services mit einer hohen Wiederverwendbarkeit einzusetzen, muss si- 
chergestellt werden, dass sich die Dienste ohne größeren Aufwand in die zu un- 
terstützenden Prozesse einbinden lassen.736 Diese Anforderung wird vom De- 
signprinzip der „Abstraktion von der Implementierungslogik“ berticksichtigt.737 
Die Einhaltung dieses Designprinzips hat zur Folge, dass Aktionen, die gemein- 
sam auftreten, in einem Service gekapselt werden können. Die Kapselung derar- 
tiger Aktionen bietet den Vorteil, dass sich die Anzahl der Services verringern 
lässt. 


733 Vgl. Balzert (2001), S. 79. An dieser Stelle ist darauf hinzuweisen, dass diese von 
BALZERT formulierte Regel allgemeingültigen Charakter besitzt, d. h. nicht auf die ex- 
plizite Wiederverwendung von Services abzielt, sondern sich auf die generellen Vorteile 
wiederverwendbarer Software bezieht. 

734 Vgl. Erl (2005), S. 209 und 302; Fiege/Stelzer (2007), S. 911. 

735 Vgl. Buxmann/Hess/Widjaja (2007), S. 1318. 

736 Vgl. hierzu Winkler (2007), S. 258. 


737 Vgl. Abschnitt 3.3.2.1. 
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5.2.2.2 Top-down-gestiitzte Serviceidentifikation 


Der folgende Abschnitt zeigt, wie sich eine Top-down-gestiitzte Identifikation 
der Berichtsservices durchführen lässt. Ausgangspunkt sind die zugrunde lie- 
genden Berichtsprozessmodelle. Ziel der Berichtsidentifikation ist es, aus den 
Berichtsprozessmodellen heraus Aktivitäten zu ermitteln, die als potenzielle Be- 
richtsservices in Frage kommen. Die dabei anfallenden Schritte sind Gegens- 
tand des Abschnitts 5.2.2.2.1, während zwei Beispiele eines potenziellen Be- 
richtsservices im anschließenden Abschnitt 5.2.2.2.2 präsentiert werden. 


5.2.2.2.1 Vorgehen 


Grundsätzlich lässt sich die Top-down-gestützte Serviceidentifikation anhand 
von drei Schritten durchführen. Die hierbei relevanten Aktivitäten werden nun 
verdeutlicht. 


Schritt 1: Ermittlung mehrfach auftretender und/oder berichtsprozess- 
übergreifender Aktivitäten 
Nach der Modellierung der zu unterstützenden Berichtsprozesse wird eine Auf- 
bereitung der Prozessmodelle dann erforderlich, wenn sich in ihnen gleichartige 
Aktivitäten bzw. Aktionen identifizieren lassen, ’38 die entweder innerhalb eines 
Berichtsprozesses mehrfach oder aber in verschiedenen Berichtsprozessen auf- 
tauchen.739 Derartige Aktivitäten sind potenzielle Berichtsservices, da sie auf- 
grund ihres mehrfachen Auftretens eine hohe Wiederverwendung in Aussicht 
stellen. Wie anhand des Aktivitätsdiagramms von Abbildung 41 zu erkennen 
ist, stellt die Aktivität 4.1 einen solchen Berichtsservicekandidaten dar, da diese 
Aktion von den übergeordneten Aktivitäten 2.3, 3.1 und 3.2 verwendet wird. 740 
Um redundante Aktivitäten zu ermitteln und zu minimieren, sind hierbei in- 
haltlich gleiche Aktivitäten auch einheitlich zu benennen. Wird keine einheitli- 
che Semantik gewährleistet, erweist sich die Identifikation mehrmals modellier- 
ter Aktivitäten mit Blick auf die mögliche Komplexität von Berichtsprozessen 
als schwierig bzw. unmöglich. Durch die eindeutige Benennung mehrfach vor- 
kommender Aktionen lässt sich sicherstellen, dass im Ergebnis Aktivitäten vor- 
liegen, die eindeutig voneinander abgrenzbare Aufgaben in dem zugrunde lie- 
genden Berichtsprozess repräsentieren. Ist dieser Zustand nicht gegeben, muss 
an dieser Stelle eine Aufbereitung der Berichtsprozessmodelle erfolgen. 


738 Die Begriffe „Aktivität“ und „Aktion“ werden im Folgenden synonym verwendet. 

739 Vgl. Winkler (2007), S. 259. 

740 In dem exemplarischen Aktivitätsdiagramm von Abbildung 41 sind die Aktivitäten 
durchnummeriert, wobei die Zahl vor dem Punkt für die Ebene steht, auf der sich die 


jeweilige Aktivität befindet. 
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Bei der Anpassung der Berichtsprozessmodelle ist dabei zu beachten, dass 
die Beziehungen zwischen den mehrmals in einem Prozess vorkommenden Ak- 
tionen und den nur einmal vorkommenden Aktivitäten erhalten bleiben. So kann 
die korrekte Ausführung der Berichtsprozesse gewährleistet werden 


Aktivität 1.1 Aktivität 1.2 Aktivität 1.3 


Aktivität 5.1 


Abbildung 41: Beispiel eines aufbereiteten Aktivitätsdiagramms 


Schritt 2: Identifikation potenzieller Berichtsservices durch Verknüpfung 
zusammenhängender Berichtsprozessaktivitäten 
Nach der Aufbereitung der zugrunde liegenden Berichtsprozessmodelle erfolgt 
die Identifikation der potenziellen Berichtsservices, die in einem Berichts- 
prozess mehrfach und/oder in verschiedenen Berichtsprozessen auftreten. Das 
entscheidende Kriterium ist hierbei, alle Aktionen bzw. Aktivitäten zu einem 
Berichtsservice zusammenzufassen, die bei der Inanspruchnahme dieses Diens- 
tes sequenziell ausgeführt werden. Die Identifikation derartiger Aktionen wird 
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mit dem Ziel durchgeführt, alle Aktionen zu ermitteln, die sich zu einem Servi- 
ce kapseln lassen. In Abbildung 41 wird deutlich, dass diese Konstellation bei 
Aktion 4.1 vorliegt, da bei dieser Aktion die Basisaktivitäten 5.1 bis 5.3 hinter- 
einander ausgeführt werden. ”’*! 


Schritt 3: Ermittlung der Häufigkeit der Serviceverwendung 

Nach der Identifikation der potenziellen Berichtsservices ist zu klären, wie häu- 
fig diese genutzt werden. Ziel dieses Schrittes ist es, den „Kandidatenkreis‘ po- 
tenzieller Berichtsservices einzugrenzen. Die Häufigkeit der Servicenutzung 
lässt sich anhand von zwei Kriterien bestimmen. Zum einen ist zu ermitteln, wie 
oft ein Service innerhalb eines bestimmten Zeitraums aufgerufen wird (liegt ei- 
ne häufige Nutzung vor, sind besonders hohe Anforderungen an die Verfügbar- 
keit des Dienstes zu formulieren).’*? Zum anderen muss bekannt sein, von wie 
vielen weiteren Diensten ein Berichtsservice nachgefragt wird. Dies wiederum 
geht mit der Frage einher, in welchen weiteren SOBP der jeweilige Berichtsser- 
vice ausgeführt werden soll. Als potenzielle Servicenachfrager kommen hier 
sowohl unternehmungsinterne als auch -externe Servicenutzer in Frage. 

In Anlehnung an WINKLER lässt sich in diesem Zusammenhang nicht präzi- 
sieren, was unter einer häufigen Serviceverwendung zu verstehen ist.’43 Ein kri- 
tischer Wert, der als Mindestgrenze für die Häufigkeit einer Servicenutzung 
dient, ist daher von jeder SOA-betreibenden Unternehmung, d. h. von der IT- 
sowie insbesondere von der Fachabteilung, welche die Nutzung des Berichts- 
services anstrebt, individuell festzulegen. 


5.2.2.2.2 Beispiele für Berichtsservicekandidaten 


Die beiden folgenden Abschnitte 5.2.2.2.2.1 und 5.2.2.2.2.2 thematisieren Bei- 
spiele von Berichtsservicekandidaten, die sowohl in einem Berichtsprozess 
mehrmalig als auch berichtsprozessübergreifend zur Anwendung kommen kön- 
nen. Charakteristisch für diese Berichtsservices ist, dass sie aus verschiedenen 
Aktionen bestehen, die stets gemeinsam auftreten. 


5.2.2.2.2.1 Berechnung verknüpfter Kennzahlen im Rahmen des Prozesses 
„Berichtserstellung“ 


Als Beispiel für eine Aktivität, die in verschiedenen SOBP zum Einsatz kom- 
men kann, lässt sich die Berechnung von Kennzahlen bzw. Key-Performance- 


741 Abschnitt 5.2.2.2.2 führt zwei Beispiele von Aktivitäten an, die als derartige Aktionen 
identifiziert werden können und sich damit als potenzielle Berichtsservices eignen. 
742 Zur Dienstgüteeigenschaft der Verfügbarkeit vgl. Abschnitt 5.2.3.4.1. 


743 Vgl. Winkler (2007), S. 261. 
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Indikatoren (KPI) anführen.’ Kennzahlen besitzen für die Unternehmungs- 
steuerung eine große Bedeutung. ’45 Mit Blick auf die in Abschnitt 2.2.2 vorge- 
stellten Kernprozesse des Berichtswesens fällt die Ermittlung von Kennzahlen 
im Rahmen des Kernprozesses ,,Berichtserstellung“ an. 

Kennzahlen dienen dazu, die Unternehmungsleitung und weitere Entschei- 
dungsträger einer Unternehmung bei der kurzfristigen und langfristigen Pla- 
nung, Steuerung und Kontrolle zu unterstützen. Sie stehen für Zahlen bzw. 
Messwerte, die messbare, betriebswirtschaftlich relevante Daten in komprimier- 
ter bzw. verdichteter Form zusammenfassen.’4 Mit Hilfe von Kennzahlen las- 
sen sich Zusammenhänge und Abhängigkeiten verdeutlichen sowie die Kom- 
plexität des dargestellten Sachverhalts reduzieren.’47 Ferner kommen Kennzah- 
len zur Definition von Sollvorgaben und -bereichen, die sich beispielsweise auf 
bestimmte Produkte, Leistungen oder Geschäftsvorfälle beziehen, zum Ein- 
satz. 748 

Mit den absoluten Kennzahlen, den Verhältniszahlen und den Richtzahlen 
werden drei Kennzahlentypen unterschieden.749 Absolute Kennzahlen lassen 
sich den Betriebsdaten entnehmen. Sie können als Einzelzahlen, Summen, Dif- 
ferenzen oder Mittelwerte ausgeprägt sein. Umsatzerlöse, das Anlagevermögen 
sowie Forderungen aus Lieferungen und Leistungen sind Beispiele für eine ab- 
solute Kennzahl. Verhältniszahlen bzw. Relativzahlen setzen absolute Zahlen in 
Beziehung zueinander. Als Ausprägungen einer Verhältniszahl lassen sich 
Gliederungszahlen, Beziehungszahlen und Indexzahlen unterscheiden. Bei 
Gliederungszahlen wird ein Teilwert zu einem Gesamtwert in Beziehung ge- 
setzt. Ein Beispiel hierfür ist die Eigenkapitalquote, die sich ergibt, wenn das 
Eigenkapital durch das Gesamtkapital dividiert wird. Eine Beziehungszahl wird 
berechnet, wenn absolute Zahlen, die in einem inhaltlichen Zusammenhang ste- 
hen, miteinander dividiert werden. Diese Konstellation liegt z. B. bei der Er- 
mittlung des Deckungsgrads 1 vor. Die Berechnungsvorschrift lautet De- 
ckungsgrad 1 = (Eigenkapital / Anlagevermögen) * 100. Indexzahlen, die auch 
als Messzahlen bezeichnet werden, zeichnen sich dadurch aus, dass gleichartige 
Zahlen, die zeitlich oder räumlich voneinander getrennt sind, zu einem Basis- 


744 Nach SIEGWART haben Kennziffern im Gegensatz zu Kennzahlen eine grundsätzliche 
Bedeutung und gehen über betriebsspezifische Sachverhalte hinaus. Vgl. Siegwart 
(2002), S. 19. Im Gegensatz zu SIEGWART wird im Hinblick auf das Ziel dieses Ab- 
schnitts eine Unterscheidung der Termini Kennzahl und Kennziffer jedoch nicht weiter- 
verfolgt. 

745 Vgl. Weber et al. (2004), S. 98. 

746 Vgl. Vollmuth/Zwettler (2006), S. 8. 

747 Hierin liegt ein Unterschied zu den Informationen, die aus der Buchhaltung stammen. 
Vgl. Vollmuth/Zwettler (2006), S. 9. 

748 Vgl. Kronz (2005), S. 35. 


749 Vgl. Zdrowomyslaw/Kasch (2002), S. 72. 
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maß zusammengeführt werden. Richtzahlen als dritte Ausprägung einer Kenn- 
zahl lassen sich ermitteln, wenn Zahlen beispielsweise einer zu analysierenden 
Unternehmung mit branchenspezifischen Durchschnittszahlen in Beziehung ge- 
setzt werden. 


Perioden- 
überschuss 


Gewinn + 
Zinsen 
Fremdkapital 


Umsatz- , Zinsen 


) - 


rentabilität (% (Fremdkapital) 


Return on 
Investment (%) 


. Eigenkapital 
Gesamt- + 
kapital 


Fremdkapital 


Kapital- 
umschlag 


Abbildung 42: ROI-Baum nach dem DuPont-Schema’>5 


Mit Blick auf das in Abschnitt 5.2.2.2.1 vorgestellte Top-down-gestützte Vor- 
gehen zur Identifikation gemeinsam auftretender Aktivitäten ist festzustellen, 
dass eine sequenzielle Ausführung mehrerer Aktionen z. B. bei der Ermittlung 
der Spitzenkennzahl eines Kennzahlensystems vorliegt. Ein Kennzahlensystem 
zeichnet sich dadurch aus, dass die Kennzahlen nicht isoliert voneinander be- 


750 Vgl. Mertens/Billmeyer/Bradl (2003), S. 802. Der Kennzahlenbaum entspricht dem Du- 


Pont-Kennzahlensystem. 
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trachtet, sondern in Beziehung zueinander gesetzt werden.’5! Ein Beispiel für 
eine solche Spitzenkennzahl ist der ROI, der berechnet wird, um die Rendite 
des eingesetzten Kapitals zu ermitteln. Abbildung 42 verdeutlicht, aus welchen 
Teilkennzahlen sich der ROI zusammensetzt. 

Wie Abbildung 42 zu entnehmen ist, werden zur Berechnung des ROI ver- 
schiedene Teilkennzahlen in mathematische Beziehungen zueinander gesetzt.752 
Aus der Perspektive der Serviceorientierung lassen sich die einzelnen Berech- 
nungen der Teilkennzahlen als separate Aktivitäten auffassen, die abgestimmt 
aufeinander ausgeführt werden müssen, um die Spitzenkennzahl zu berechnen. 
Folglich lassen sie sich zu einem Berichtsservice kapseln, der die Berechnung 
des ROI zum Ziel hat. 


5.2.2.2.2.2 XBRL-Validierung von Jahresabschlussdaten im Rahmen der 
Prozesse „Informationsbeschaffung“ und „Berichtsdistribution“ 


Als weiteres Beispiel für einen Berichtsservice, der innerhalb eines Berichts- 
prozesses mehrfach oder in verschiedenen SOBP verwendet werden kann, ist 
ein Dienst zu nennen, der die Validierung von XBRL-Instanzdokumenten über- 
nimmt. Ein solcher Service kann beispielsweise die Aufgabe erfüllen, Bilanzen, 
die nach einem bestimmten Rechnungslegungsstandard erstellt wurden und als 
XBRL-Instanzdokument vorliegen mit der XBRL-Taxonomie zu validieren, 
welche den zugrunde liegenden Rechnungslegungsstandard abbildet, nach dem 
das Instanzdokument erstellt wurde. 

Eine derartige Validierung von Bilanzinformationen ist empfehlenswert, um 
die semantische Korrektheit der zu verarbeitenden Informationen zu garantie- 
ren. Ein Anwendungsfall ergibt sich bei der Konzernkonsolidierung, bei der die 
Bilanzen der Töchterunternehmungen zunächst beschafft werden müssen. Die 
Bilanzen der Töchter lassen sich einerseits als Dokumente in einem proprietären 
Datenformat anliefern. Alternativ können die Tochterbilanzen als XBRL- 
Instanzen zur Verfügung gestellt werden. Um sicher zu gehen, dass die Inhalte 
der Instanzen dem zugrunde liegenden Rechnungslegungsstandard genügen, 
sind die Dokumente mit der entsprechenden XBRL-Taxonomie zu validieren. 
Die beim Validierungsprozess anfallenden Aktionen lassen sich zu einem Be- 


75l Damit bilden Kennzahlensysteme die Grundlage für Berichtsprozesse, die auf das 
Benchmarking ausgerichtet sind. Als Benchmarking wird der Vergleich mit anderen 
Wirtschafts- oder Verwaltungssubjekten auf Basis identisch erhobener Messgrößen ver- 
standen. Zum Vergleich wird der Beste einer Branche herangezogen. Durch den Einsatz 
von Kennzahlensystemen lässt sich nicht nur Wissen in komprimierter Form über die 
abgebildete Realität des betrachteten Subjekts abbilden, sondern lassen sich auch Ver- 
änderungsprozesse anstoßen. 

752 Wie in der Abbildung 42 deutlich wird, ergibt sich der ROI, indem die Umsatzrentabili- 
tät mit dem Kapitalumschlag multipliziert wird, während sich dieser durch die Division 


des Umsatzes mit dem Gesamtkapital ermitteln lässt. 
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richtsservice kapseln, der bei Bedarf in einem Berichtsprozess ausgeführt wer- 
den kann. 


5.2.2.3 Bottom-up-gestiitzte Serviceidentifikation 


Den bisherigen Ausführungen zur Berichtsserviceidentifikation lag eine Top- 
down-gestützte Vorgehensweise zugrunde. Um dem für die konzeptionelle Ges- 
taltung eines SOBP geeigneten Meet-in-the-middle-Ansatz gerecht zu werden, 
ist die bestehende Betrachtung um eine Bottom-up-gestützte Vorgehensweise 
zu erweitern. 

Mit Blick auf das Ziel, Berichtsservices zu verwenden, die sich durch einen 
hohen Wiederverwendungsgrad auszeichnen, ist im Rahmen der Bottom-up- 
gestützten Serviceidentifikation zum einen zu analysieren, welche geeigneten 
Berichtsdienste von unternehmungsexternen Providern genutzt werden können. 
Zum anderen hat die Bottom-up-gestützte Vorgehensweise zum Ziel, alle unter- 
nehmungsinternen IS, die von ihnen vorgehaltenen Daten sowie bereitgestellten 
Funktionen zu analysieren, die sich zur Ausführung der Berichtsprozesse nutzen 
lassen. Hierbei muss eine Analyse der Systemschnittstellen erfolgen. In diesem 
Zusammenhang kann es sich z. B. um proprietäre Schnittstellen, Datenbanken 
und Web Services handeln. Um dabei den Überblick über die betriebenen 
Schnittstellen zu wahren, sollten alle identifizierten Schnittstellen funktionalen 
Domänen zugeordnet werden.’53 

Nach der Analyse der Schnittstellen sind in einem nächsten Schritt sämtliche 
Operationen bzw. Funktionen zu identifizieren, die von den betriebenen IS zur 
Verfügung gestellt werden. In Frage kommen hierfür alle lesenden und schrei- 
benden Operationen. Ein Beispiel für lesende Operationen ist der automatisierte 
Import von Bilanzen der Töchter einer Unternehmung. Beispiele für lesende 
und schreibende Operationen sind die Teilschritte, die im Rahmen eines ETL- 
Prozesses ausgeführt werden.’54 Ferner sind bei der Identifizierung der Operati- 
onen auch alle Funktionen zu berücksichtigen, denen eine Verarbeitungslogik 
zugrunde liegt. Als Beispiel hierfür sind die Berechnungsvorschriften von 
Kennzahlen zu nennen, die in einer Berichtsanwendung beispielsweise zur Er- 
stellung einer Balanced Scorecard genutzt werden. 

Neben der Identifikation von Serviceoperationen spielt auch die Identifikati- 
on der Datenobjekte, die von den zugrunde liegenden IS zur Verarbeitung der 


753 Vgl. hierzu Offermann (2008), S. 466. 


754 Vgl. Abschnitt 5.2.2.2.1 
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Geschäfts- und Finanzinformationen verwendet werden, eine wichtige Rolle.755 
Als Grundlage zur Identifikation der Datenobjekte lassen sich die semantischen 
und konzeptionellen bzw. logischen Datenmodelle der IS nutzen.’56 Da auf- 
grund der Vielzahl der zum Einsatz kommenden IS bzw. Datenmodelle die Da- 
tenobjekte in diesem Zusammenhang typischerweise unterschiedlich bezeichnet 
sind, ist es notwendig, die Datenobjekte dieser Datenmodelle zu konsolidieren. 

Da zwischen den Datenobjekten eines Datenmodells vielfältige Beziehungen 
existieren, reicht es bei der Konsolidierung nicht aus, nur die Bezeichnung der 
Datenobjekte zu betrachten bzw. anzupassen. Stattdessen sind Verfahren der 
Schemaintegration sowie des Schema-Mappings anzuwenden, um eine konsi- 
stente und korrekte Sicht auf die Bedeutung der Datenobjekte sowie der zwi- 
schen den Objekten bestehenden Beziehungen zu erreichen.’5” Für ähnliche 
oder gleiche Datenobjekte sind Objekte zu erstellen, die alle Eigenschaften der 
Datenobjekte enthalten, die sie vereinen. Um die Konsolidierung der Datenmo- 
delle zu erleichtern, ist es dabei empfehlenswert, die Datenobjekte nach funkti- 
onalen Domänen zu gruppieren. 


5.2.3 Fachliche Servicegestaltung 


Die fachliche Servicegestaltung ist die letzte Phase der konzeptionellen Gestal- 
tung eines SOBP. Ziel dieser Phase ist es, den Leistungsumfang bzw. die Funk- 
tionalität der identifizierten Berichtsservices zu definieren.’5® Die fachliche 
Gestaltung von Services hat vor allem vor dem Hintergrund erster SOA- 
Umsetzungen in der Praxis eine große Bedeutung. Diese Projekte haben ge- 
zeigt, dass sich die Flexibilitätsanforderungen, die derzeit an Applikationsland- 
schaften gestellt werden, durch die rein technische Zerlegung eines IS in Servi- 
ces nicht zufriedenstellend erfüllen ließen. 759 

Neben einer fachlichen Eignung der Dienste, die durch die Flexibilisierung 
und/oder Automatisierung der Berichtsprozesse einen betriebswirtschaftlichen 
Mehrwert generieren sollen, ist bereits bei der fachlichen Servicegestaltung zu 


755 Ausgedriickt in der Begriffswelt der Entity-Relationship-Modellierung (ER- 
Modellierung) werden im Folgenden als Datenobjekte sowohl die Entity-Types als auch 
die Attribute der Entity-Types aufgefasst. Zur ER-Modellierung vgl. Gabriel/Röhrs 
(1995), S. 104f. 

756 Zu den Merkmalen und Unterschieden dieser beiden Ausprägungen eines Datenmodells 
vgl. Gabriel/Röhrs (1995), S. 104ff. 

757 Das Vorgehen zur Schemaintegration sowie zum Schema-Mapping wird bei LESER/ 
NAUMANN beschrieben. Vgl. Leser/Naumann (2007), S. 116ff. 

758 Die Bestimmung des Leistungsumfangs von Services ist von Bedeutung, damit Dienste 
nicht nur einen technischen, sondern auch einen fachlichen Nutzen generieren. Vgl. 
hierzu Tilkov/Starke (2007), S. 14. 


759 Vgl. Esch et al. (2008), S. 94. 
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berücksichtigen, dass sich die identifizierten Services auch für eine spätere Rea- 
lisierung eignen.’60 Die Anforderungen, die dies sicherstellen, werden in Ab- 
schnitt 5.2.3.1 diskutiert. Die fachliche Berichtsservicegestaltung beginnt in 
Abschnitt 5.2.3.2 mit der Kategorisierung des Leistungsumfangs der identifi- 
zierten Berichtsservices. Darauf aufbauend ist zu überprüfen, inwieweit sich die 
zur Verfügung stehenden XBRL-Taxonomien zur semantischen Beschreibung 
der von einem Berichtsservice verarbeiteten Geschäfts- und Finanzinformatio- 
nen nutzen lassen (Abschnitt 5.2.3.3). In Abschnitt 5.2.3.4 wird ein Vorgehen 
zur Bewertung der Dienstgüteeigenschaften der im Rahmen der Bottom-up- 
Analyse identifizierten unternehmungsinternen Services oder Dienste eines un- 
ternehmungsexternen Anbieters erarbeitet. Zum Abschluss fokussiert Abschnitt 
5.2.3.5 eine Methode zur fachlichen Gestaltung neu zu entwickelnder Berichts- 
services. 


5.2.3.1 Anforderungen zur fachlichen Servicegestaltung 


Mit Blick auf das Ziel einer SOA, eine hohe Wiederverwendbarkeit von Diens- 
ten zu ermöglichen, lassen sich fünf Anforderungen zur fachlichen Gestaltung 
von Services identifizieren. Diese werden nachfolgend erläutert. 


Anforderung 1: Normale Serviceoperationen 

Die erste Anforderung fokussiert die Gestaltung so genannter normaler Service- 
operationen. Die Anforderung der Normalität lässt sich aufteilen in die Teilan- 
forderungen der Vollständigkeit und der Redundanzfreiheit. Die Anforderung 
der Vollständigkeit sieht vor, dass die Operationen, die ein Service ausführt, die 
gesamte an ihn geforderte Funktionalität abdecken.’6! Dies betrifft sowohl 
schreibende als auch lesende Operationen. Die Redundanzfreiheit zielt darauf 
ab, dass kein Service eingesetzt werden darf, dessen Funktionalität bereits von 
einem anderen Dienst erbracht wird.’62 Dies hat folglich zur Konsequenz, dass 
ein entsprechender Berichtsservice exakt einmal vorkommen darf. Wie 
HESS/HUMM/VOss in diesem Zusammenhang bemerken, gilt die Forderung der 
Redundanzfreiheit ausschließlich für Basis- und Funktionsservices. Eine In- 
kaufnahme redundanter Prozessservices ist hingegen möglich, falls dies aus 
Gründen der Performance und Nutzungsfreundlichkeit der Schnittstelle erfor- 
derlich ist.763 


760 Vgl. Beverungen/Knackstedt/Müller (2008), S. 223. 
761 Vgl. Humm/Juwig (2006), S. 3. 
762 Vgl. Gimnich (2007), S. 68. 


763 Vgl. Hess/Humm/Voss (2006), S. 403. 
Alexander Pastwa - 978-3-631-75488-7 


Downloaded from PubFactory at 01/11/2019 04:20:29AM 
via free access 


178 Konzeptionelle Gestaltung Serviceorientierter Berichtsprozesse 


Anforderung 2: Idempotente Serviceoperationen 

Die Anforderung der Idempotenz hat zur Aussage, dass mehrmalige Aufrufe ei- 
nes Services zu genau dem Ergebnis führen müssen, welches aus der einmaligen 
Nutzung dieses Dienstes resultiert.7% Der wiederholte Aufruf eines Services, 
der z. B. im Rahmen des Kernprozesses Berichtsproduktion den Kapitalwert ei- 
ner Investition berechnet,’® darf folglich nicht zu abweichenden Ergebnissen 
führen. Gleiche Ergebnisse wiederum setzen voraus, dass sich die Datengrund- 
lage — im hier betrachteten Beispiel die Zahlungsüberschüsse, die Laufzeit der 
Investition und der zugrunde liegende Diskontierungszinssatz — zwischen den 
entsprechenden Serviceaufrufen nicht geändert hat. 


Anforderung 3: Datenhoheit der Basisservices 

Die Anforderung der Datenhoheit der Basisservices besagt, dass der Zugriff auf 
die Informationsobjekte eines IS, das Bestandteil einer SOA ist, über Basisser- 
vices erfolgen muss. D. h., alle lesenden und schreibenden Serviceoperationen 
sind mit Hilfe dieser Serviceart durchzuführen. Ziel ist es dabei, dass jeder Ba- 
sisservice einen disjunkten Ausschnitt aller Informationsobjekte verwaltet. 


Anforderung 4: Wahrung der Abhängigkeitsbeziehungen zwischen den 
Servicekategorien 
In Abschnitt 4.2.2.1 ist bereits deutlich geworden, dass sich die im Rahmen ei- 
ner SOA zur Anwendung kommenden Services anhand der Kategorien Be- 
standsservices, Funktionsservices und Prozessservices systematisieren lassen. 
Um Services miteinander verknüpfen zu können, ist es erforderlich, die Abhän- 
gigkeitsbeziehungen zwischen diesen drei Servicekategorien aufrechtzu- 
erhalten. Die Abhängigkeitsbeziehungen zwischen zwei Services können hier- 
bei als „kennt“-, „ruft auf“- oder „bezieht Daten von“-Aussagen formuliert wer- 
den. In Anlehnung an Hess/Hum/Voß lassen sich dann folgenden Abhängig- 
keitsbeziehungen identifizieren:766 
e Prozessservices sollen höchstens abhängig untereinander sowie abhängig 
zu Funktions- und Bestandsservices sein. 
e Funktionsservices sollen höchstens abhängig untereinander sein sowie ab- 
hängig zu Bestandsservices sein. 
e Bestandsservices sollen ausschließlich abhängig untereinander sein. 


764 Wie HUMM/JUWIG bemerken, stammt diese Idee aus der Batch-Verarbeitung. Die Idem- 
potenz garantiert in diesem Kontext, dass ein versehentlich angestoßener Batch-Lauf 
nicht zu einem unerwünschten bzw. fehlerhaften Ergebnis führt. Vgl. Humm/Juwig 
(2006), S. 3. 

765 Zur Kapitalwertmethode vgl. z. B. Busse von Colbe/Laßmann (1990), S. 6ff; Ross/ 
Westerfield/Jaffe (1999), S. 64ff. 


766 Vgl. Hess/Humm/Voss (2006), S. 401. 
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Anforderung 5: Kontextfreie Serviceoperationen 

Eine weitere Anforderung betrifft die Kontextfreiheit der Serviceoperationen. 
Nach HEss/HuM/Voss lässt sich diese Anforderung aus der Perspektive des 
Session- sowie des Transaktionskontextes betrachten.’67 Serviceoperationen, 
die sessionkontextfrei sind, zeichnen sich dadurch aus, dass sie keine Informa- 
tionen über den Servicenutzer, über die zugrunde liegenden Sessions sowie den 
Aufrufkontext benötigen. Ebenso soll die Berechtigungsprüfung außerhalb der 
fachlichen Funktionalität bzw. Operation des jeweiligen Services durchgeführt 
werden. 

Die Anforderung, kontextfreie Serviceoperationen zu gestalten, gewährleistet 
darüber hinaus, dass sich Services als Transaktionen auffassen lassen. D. h., ein 
Dienst wird entweder vollständig oder gar nicht ausgeführt. Die Kontextfreiheit 
von Serviceoperationen hat damit zur Folge, dass kompensierende Operationen 
ebenfalls implementiert werden müssen, die beispielsweise im Falle einer feh- 
lerhaften Ausführung eines Service aufgerufen werden. 768 


5.2.3.2 Kategorisierung der potenziellen Berichtsservices 


Bevor Dienste implementiert werden, ist beim Entwurf der Dienste die Aufgabe 
zu erfüllen, Services in verschiedene Kategorien einzuordnen.769 Allgemein 
wird mit der Kategorisierung der Services das Ziel verfolgt, die betriebswirt- 
schaftliche Funktionalität der in einer SOA zum Einsatz kommenden Dienste 
klar voneinander abzugrenzen.” Die Anforderung, die identifizierten Services 
hinsichtlich ihres Aufgabenumfangs zu klassifizieren, ist daher auch bei der 
fachlichen Gestaltung der Berichtsservices von großer Bedeutung. 

Die Kategorisierung der Berichtsservices fokussiert nicht nur auf die (be- 
triebswirtschaftlichen) Aufgaben, die ein Berichtsservice erbringen soll. Auch 
unterstützende Aktionen, die (als Berichtsservice gekapselt) zur Erfüllung einer 
betriebswirtschaftlichen Funktionalität beitragen, sind anhand geeigneter Kate- 
gorien zu klassifizieren. Ein Beispiel für einen Berichtsservice, der derartige 
Aktionen ausführt, ist ein Dienst, der das Einlesen von Geschäfts- und Finanz- 
informationen ermöglicht, die im Rahmen des Kernprozesses Berichtsprodukti- 
on verwendet werden. Als geeignete Klassen lassen sich für die Kategorisierung 
der potenziellen Berichtsservices die in Abschnitt 4.2.2.1 vorgestellten Service- 
arten Datenservices, Funktionsservices und Prozessservices verwenden. 

Mit der Kategorisierung von Berichtsservices lassen sich zwei Teilziele erfül- 
len. Erstens bewirkt die Zuweisung eines Services zu einer Serviceart eine bes- 


767 Vgl. Hess/Humm/Voss (2006), S. 404. 
768 Vgl. Humm/Juwig (2006), S. 3. 
769 Vgl. Beverungen/Knackstedt/Müller (2008), S. 223. 


770 Vgl. Klose/Knackstedt (2007), S. 47. 
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sere Pflege des Serviceportfolios. Da zu erwarten ist, dass der Servicebestand 
im Laufe der Nutzung einer SOA wachsen wird, ist frühzeitig Sorge zu tragen, 
dass die Services anhand eines zusätzlichen Kriteriums „Serviceart‘‘ systemati- 
siert werden und sich folglich im Laufe ihrer Nutzung in einem Servicever- 
zeichnis leichter auffinden lassen. Zweitens ist die Kategorisierung der Services 
erforderlich, um Anforderung 4 bei der fachlichen Gestaltung von Services zu 
erfiillen.’”7! Diese Anforderung beinhaltet, dass Abhängigkeiten zwischen den 
Servicearten gewahrt werden müssen, um eine effektive (d. h. eine konsistente 
und korrekte) Gestaltung der Services sowie ihrer Beziehungen zueinander mit 
dem Ziel zu gewährleisten, eine effiziente Ausführung der Serviceorientierten 
Prozesse zu ermöglichen. 


5.2.3.3 Zuweisung von XBRL-Taxonomieelementen 


Nachdem die in Frage kommenden Berichtsservices einer Kategorie zugeordnet 
wurden, ist zu entscheiden, welche XBRL-Taxonomien zum Einsatz kommen 
sollen, um die zu verarbeitenden Geschäfts- und Finanzinformationen seman- 
tisch zu beschreiben. Je nach verfolgtem Berichtszweck können XBRL FR- 
Taxonomien, die XBRL GL-Taxonomie sowie beide Taxonomiekategorien in 
kombinierter Form zum Einsatz kommen. Zu prüfen ist, welche Input- 
informationen, die als Eingabewerte zur Ausführung einer Serviceoperation be- 
nötigt werden, sich mit Hilfe der zur Verfügung stehenden XBRL-Elemente der 
jeweiligen Taxonomie auszeichnen lassen. In gleicher Weise ist mit den Out- 
putwerten zu verfahren. 


5.2.3.4 Bewertung der Dienstgüte bereits vorhandener interner oder ex- 
terner Berichtsservices 


Bevor mit der fachlichen Gestaltung neuer Berichtsservices begonnen wird, ist 
zu prüfen, inwieweit sich die im Rahmen der Bottom-up-Analyse identifizierten 
unternehmungsinternen Services oder Dienste eines unternehmungsexternen 
Anbieters zur konzeptionellen Gestaltung des SOBP nutzen lassen. Um die Eig- 
nung eines Berichtsservices zu bestimmen, ist es nötig, die Dienstgüte der po- 
tenziellen Services einer kritischen Bewertung zu unterziehen. Die Bewertung 
der Dienstgüte der Services ist von Bedeutung, da die am höchsten bewerteten 
Dienste potenzielle Kandidaten für eine softwaretechnische Implementierung 
darstellen.?72 

Da bei einem SOBP alle Vorgänge zur Verarbeitung der berichteten Ge- 
schäfts- und Finanzinformationen durch die Inanspruchnahme von Services 


7171 Vgl. Abschnitt 5.2.3.1. 


772 Vgl. hierzu Gimnich (2007), S. 73. 
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durchgeführt werden sollen,?73 muss bei der Gestaltung und dem Betrieb eines 
derartigen Prozesses gewährleistet sein, dass nur diejenigen Dienste zum Ein- 
satz kommen, welche die im Rahmen des Servicevertrags vereinbarten Dienst- 
güteeigenschaften erfüllen.’’”%* Die Einhaltung der Dienstgüteeigenschaften ist 
sowohl während der Nutzung als auch Entwicklung neuer Services oder Modi- 
fizierung bestehender Dienste zu gewährleisten. In gleicher Weise müssen Ser- 
vices, die je nach Berichtszweck von unternehmungsexternen Akteuren bereit- 
gestellt werden, hinsichtlich ihrer Eignung überprüft werden. 

Um die Dienstgüteeigenschaften zu überwachen, reicht es daher nicht aus, 
geeignete Qualitätskriterien zu definieren und technische Komponenten einzu- 
setzen, die die Einhaltung der Dienstgüteeigenschaften garantieren. Darüber 
hinaus ist es erforderlich, Bewertungsmechanismen einzubinden, welche Ent- 
scheidungen untermauern, ob ein neu entwickelter, ein modifizierter oder extern 
bereitgestellter Service in das Dienstportfolio der Unternehmung aufgenommen 
und zur Nutzung freigegeben werden kann. 

Zur Systematisierung der Inhalte einer Servicebeschreibung lassen sich die 
Informationen, die anhand quantitativer Kriterien beurteilt werden können, von 
denen unterscheiden, die eine qualitative Bewertung erfordern.’75 Im Vergleich 
zu den qualitativen Kriterien bietet der Einsatz von quantitativen Kriterien den 
Vorteil, dass ihnen objektiv messbare Werte zugeordnet werden. Sowohl die 
quantitativen als auch die qualitativen Dienstgüteeigenschaften sind Gegens- 
tand von Service Level Agreements (SLA).776 Ein SLA gleicht einem Vertrag 
zwischen einem Servicegeber und einem Servicenehmer und beinhaltet Parame- 
ter, die als Service Level Objects (SLO) bezeichnet werden und das Qualitätsni- 
veau der zu erbringenden Funktionalität spezifizieren.””7 Die Dienstgüte wird in 
diesem Zusammenhang auch als Quality of Service (QoS) bezeichnet. 778 


773 Vgl. Abschnitt 4.1. 

774 Generell stellen Verträge die Voraussetzung dar, dass Kooperationen zustande kommen. 
Ein Vertrag enthält alle expliziten oder impliziten Vereinbarungen zwischen den betei- 
ligten Vertragsparteien, die eine bindende Wirkung für diese haben. Vgl. Scholtis 
(1998), S. 23. Mit Blick auf den vorliegenden Untersuchungsgegenstand wird ein derar- 
tiger Vertrag im Rahmen eines Service Level Agreements abgeschlossen. 

775 Diese Unterscheidung geht auf den Vorschlag von BERBNER ET AL. zurück. Vgl. Berbner 
et al. (2005), S. 270f. Einen alternativen Ansatz zur Systematisierung der Informationen, 
die in einer Servicespezifikation enthalten sind, präsentiert LIEBHART. Seinem Vor- 
schlag zufolge enthält eine Servicebeschreibung organisatorische, technische sowie pla- 
nerische Informationen zu einem Service. Vgl. Liebhart (2007), S. 164ff. 

776 Vgl. Josuttis (2007), S. 386. 

777 Vgl. Hermann/Müller (2008), S. 237; Herden et al. (2006), S. 135; Berbner et al. (2005), 
S. 270. 


778 Vgl. Ernst (2000), S. 675. 
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Nachdem in Abschnitt 5.2.3.4.1 die Qualitätsparameter erläutert werden, die 
sich zur Beurteilung von Services nutzen lassen, stellt Abschnitt 5.2.3.4.2 das 
Vorgehen zur Bewertung der Servicequalität vor. 


5.2.3.4.1 Qualitätskriterien zur Bewertung der Berichtsservices 


Unter den objektiv messbaren Anforderungen lassen sich als mögliche Kriterien 
die Verfügbarkeit (Availability), Leistungsfähigkeit (Performance), Fehlerhäu- 
figkeit (Error Rate) sowie die Kosten der Servicenutzung anführen.’ Eine 
Übersicht über diese und weitere quantitative und qualitative Kriterien zeigt 
Abbildung 43. 


Qualitätskriterien 
Quantitative Qualitative 
Ausprägung Ausprägung 


ible Dokumenta- 
Leistungs- Fehler- 


Abbildung 43: Übersicht der Qualitätskriterien zur Beurteilung der Dienstgiite 


In Anlehnung an den Begriff der Verfügbarkeit eines IS informiert die Verfüg- 
barkeit eines Services über die Wahrscheinlichkeit, dass ein Dienst zur Nutzung 
zur Verfügung steht.780 Ein Service lässt sich als verfügbar bezeichnen, wenn es 
diesem gelingt, eine Anfrage in einer geforderten Zeit zu verarbeiten. Das Krite- 
rium der Leistungsfähigkeit wird in die Teilkriterien Durchsatz (Throughput) 
und Antwortzeit (Response Time) separiert.78! Die Antwortzeit setzt sich wie- 


779 Vgl. Berbner et al. (2005), S. 270. 
780 Vgl. Hansen/Neumann (2005), S. 287. 


781 Vgl. Berbner et al. (2005), S. 270. 
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derum aus der Zeit zusammen, die zur Übertragung und Bearbeitung der Anfra- 
ge verwendet wird, sowie der Zeit, die ein Service benötigt, um die angeforderte 
Antwort dem Servicenutzer zur Verfügung zu stellen. Die Fehlerhäufigkeit lie- 
fert eine Aussage über die Anzahl der Fehler, die innerhalb eines bestimmten 
Zeitraums aufgetreten sind. Als Fehlerursachen kommen z. B. fehlerhafte Er- 
gebnisse oder Übertragungsfehler in Frage. 

Neben der Verfügbarkeit, Leistungsfähigkeit und Fehlerhäufigkeit beschrei- 
ben die Kosten, die mit der Servicenutzung verbunden sind, eine weitere wich- 
tige Eigenschaft eines Berichtsservice.’82 Zur Abrechnung eines Services steht 
eine Vielzahl von Varianten zur Verfügung. Diesen liegt jeweils eine nutzenab- 
hängige oder nutzenunabhängige Abrechnung zugrunde. Während bei der nut- 
zenunabhängigen Abrechnung die Servicenutzung zu einem zuvor vereinbarten 
Pauschaltarif erfolgt, können Services im Rahmen einer nutzenabhängigen Ab- 
rechnung beispielsweise nach der Anzahl der Aufrufe in Rechnung gestellt 
werden. Darüber hinaus bietet sich hier die Möglichkeit an, Dienste nach dem 
Datenvolumen oder der in Anspruch genommenen Nutzungsdauer abzurechnen. 

Bei den qualitativen Kriterien sind vor allem die Sicherheit, die Reputation 
des Serviceproviders sowie der Dokumentationsgrad eines Services relevant. 783 
Die Anforderung der Sicherheit lässt sich anhand der Teilkriterien Authentizi- 
tät, Autorisierung, Vertraulichkeit und Datenverschlüsselung betrachten. Die 
Reputation des Serviceproviders liefert eine Aussage zu den Erfahrungen, die 
zum gegebenen Zeitpunkt mit den Diensten eines Serviceanbieters gemacht 
wurden. Dieses Kriterium spielt insbesondere bei der Nutzung von Services ei- 
ne Rolle, die von einem unternehmungsexternen Anbieter bereitgestellt werden. 
Hierbei ist zu evaluieren, ob es sich bei dem Serviceprovider um einen seriösen 
und bekannten Anbieter handelt. Ein weiterer Aspekt, der in diesem Zusam- 
menhang die Bewertung der Reputation eines Serviceproviders beeinflusst, 
richtet sich auf die Existenz sowie die Qualität einer Supportabteilung des 
Dienstanbieters. Insbesondere im Fall des Serviceausfalls oder bei notwendig 
gewordenem Änderungsbedarf eines Dienstes ist dieses Kriterium von tragen- 
der Bedeutung. 

Der Dokumentationsgrad eines Services repräsentiert, ob und inwieweit Än- 
derungen, welche im Laufe des Lebenszyklus eines Dienstes anfallen, nachvoll- 
ziehbar belegt sind. Informationen, die den Dokumentationsgrad eines Berichts- 
services beschreiben, müssen beispielsweise darüber Aufschluss geben, wer den 
Berichtsservice erstellt hat, wann der Service das letzte Mal geändert wurde und 
warum er modifiziert wurde. Auf diese Weise lassen sich Verantwortlichkeiten 
für die Pflege eines Services zuweisen. Das Kriterium des Dokumentationsgrads 


782 Auf die Bedeutung, zur Dynamisierung von Serviceketten Bepreisungs- und Abrech- 
nungsmodelle einzusetzen, verweisen Beimborn/Mintert/Weitzel (2002), S. 278. 


783 Vgl. Berbner et al. (2005), S. 270. 
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ist vor allem für Berichtsservices von Bedeutung, die häufig angepasst oder 
verändert werden müssen. 


5.2.3.4.2 Vorgehen zur Bewertung der Dienstgüte 


Bei der Vorgehensweise zur Bewertung der Dienstgüte der identifizierten un- 
ternehmungsinternen und -externen Berichtsservices ist zu unterscheiden, ob 
sich qualitative und/oder quantitative Kriterien verwenden lassen. Um eine Be- 
wertung der quantitativ messbaren Kriterien (Verfügbarkeit, Leistungsfähigkeit, 
Fehlerhäufigkeit und Kosten) vorzunehmen, sind adäquate Gewichte festzule- 
gen, welche die Bedeutung der jeweiligen Teilanforderung für die Beurteilung 
der Dienstgüte widerspiegeln.784 Da die Ausprägungen, die zur Bewertung der 
quantitativen Kriterien zum Einsatz kommen, in verschiedenen Einheiten vor- 
liegen, ’85 ist es zweckmäßig, die zugeordneten Werte zu normalisieren.786 Auf 
diese Weise lässt sich die Vergleichbarkeit der eingesetzten Services realisieren. 
Dabei hängt die Normalisierung davon ab, ob das Ziel des jeweiligen Kriteri- 
ums ein hoher oder niedriger Wert ist. Während bei der Antwortzeit und der 
Fehlerhäufigkeit ein kleiner Wert angestrebt wird, liegt bei der Verfügbarkeit 
und beim Durchsatz der umgekehrte Fall vor. Die Normalisierung der Antwort- 
zeit und der Fehlerhäufigkeit lässt sich durchführen, indem aus einer Auswahl n 
der zur Verfügung stehenden Services der Dienst mit der längsten Antwortzeit 
bzw. der größten Fehlerhäufigkeit durch den zu bewertenden Service dividiert 
wird. 

Bei Kriterien, bei denen möglichst hohe Werte wünschenswert sind (Verfüg- 
barkeit und Durchsatz), werden der Zähler und der Nenner vertauscht. D. h., der 
zu bewertende Service wird durch den Dienst dividiert, der die geringste Wert- 
ausprägung bezüglich des betrachteten Kriteriums (Verfügbarkeit und Durch- 
satz) aufweist. 

Im Vergleich zu den quantitativen Kriterien ist bei den qualitativen Kriterien 
eine manuelle Bewertung der Dienstgüteeigenschaft seitens der IT- 
Verantwortlichen und/oder des Berichtsempfängers erforderlich. Zur qualitati- 
ven Beurteilung des Kriteriums lässt sich eine Bewertungsmatrix einsetzen, wie 


784 Die Gewichtung ist eine häufig angewendete Möglichkeit zur Lösung von Zielkonflik- 
ten bei multikriteriellen Entscheidungsproblemen. Die verschiedenen quantitativ und 
qualitativ bewerteten Kriterien werden jeweils mit Faktoren gewichtet. Diese individuel- 
len Gewichtungsfaktoren sind Maßstabsfaktoren, die das Verhältnis der einzelnen Fak- 
toren zum Gesamtnutzen fixieren. Formal besteht die Zielgewichtung in der Multiplika- 
tion der Wertausprägungen mit ihren nichtnegativen Gewichten und der Addition der so 
gewichteten Kriterien. Auf diese Weise lässt sich ein Service bestimmen, der den höchs- 
ten Nutzen liefert. Vgl. Jenner (2000), S. 330. 

785 Siehe hierzu Abbildung 44. 


786 Vgl. Berbner et al. (2005), S. 271. 
Alexander Pastwa - 978-3-631-75488-7 


Downloaded from PubFactory at 01/11/2019 04:20:29AM 
via free access 


Vorgehensmodell zur konzeptionellen Gestaltung Serviceorientierter Berichtsprozesse 185 


sie exemplarisch in Abbildung 44 dargestellt ist. Festzuhalten ist, dass der zu 
bewertende Service in diesem Beispiel nutzungsabhängige Kosten von 10 Cent 
pro Aufruf verursacht. Zur Authentifizierung kommt X.509 zum Einsatz,’8? 
während die Autorisierung auf Basis des Advanced Encryption Standard (AES) 
erfolgt.’88 Die bisherigen Erfahrungen mit dem Provider des Services sowie mit 
dem Service selbst wurden als gut bzw. sehr gut eingeschätzt. Externe Referen- 
zen sind existent und lassen sich über ein Informationsportal einsehen. 

Die letzte Spalte verdeutlicht, dass die qualitativen Kriterien individuell be- 
wertet werden müssen, wobei im vorliegenden Beispiel eine Bewertung von 5 
Punkten auf eine herausragende Eignung des Dienstes im Hinblick auf die 
zugrunde liegende Anforderung deutet. Neben den individuellen Bewertungen 
enthält die Bewertungsmatrix die Gewichtungsfaktoren, die sowohl für die 
quantitativen als auch für die qualitativen Faktoren festgelegt werden müssen. 


evichtung Ô Punkte: irrelevant. 16 Punkte relevant 
euertung Ô Punkte ee 5 Punkte herausragend 
_ Verfügbarkeit(immp | 99 | gg | _ | 
Durchsatz (inn Nachrichten pro Minute) | 360 | 7 | = | 
Antwortzeit(in Millisekunden) | 33 | 9 | = 
Fehlerhäufigkeit (n Fehler pro Tag) | 1 3 | 1 | = 


Tarif(inCent/Aufruf) | 10 | 6 


OOOO E A —— E 
— [ee 


Feputa Be Kertatrüngen mit dem Provider| Gute te Erfahrungen 


Bisherige Erfahrungen mit dem Web 
Service Sehr gute Erfahrungen 


Externe Referenzen Informationsportal 
Dokumentationsgrad Gut dokumentiert — 


Abbildung 44: Beispiel einer Bewertungsmatrix 


Um eine abschließende Bewertung der Dienstgüte vorzunehmen, ist es erforder- 
lich, die gewichteten qualitativen und die gewichteten sowie normalisierten 
quantitativen Kriterien zu einem Gesamtergebnis zu verdichten. Für diesen 


787 Bei X.509 handelt es sich um einen Standard für digitale Zertifikate. Vgl. Schwenk 
(2005), S. 22ff.; Federrath/Pfitzmann (2006), S. 283. 
788 AES ist ein symmetrisches Verschlüsselungsverfahren, das mit einer Schlüssellänge von 


128, 192 und 256 Bit arbeitet. Vgl. Schwenk (2005), S. 8f. 
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Zweck lässt sich z. B. eine lineare Bewertungsfunktion nutzen, ’8 so dass sich 
die Dienstgüte eines Services als Summe der gewichteten Wertausprägungen 
der Einzelkriterien ermitteln lässt. Auf diese Weise können sowohl die unter- 
nehmungsexternen als auch die -internen Services vor dem Hintergrund ihrer 
Dienstgüteeigenschaften miteinander verglichen werden. Durch die Wahl der 
Gewichte lassen sich zudem einsatzspezifische Besonderheiten berücksichti- 
gen. 79 


5.2.3.5 Fachliche Gestaltung neuer Berichtsservices 


Charakteristisch für das Berichtswesen ist, dass zur Erstellung der berichteten 
Geschäfts- und Finanzinformationen Berechnungsvorschriften genutzt werden 
(müssen), die entweder vom Gesetzgeber im Rahmen eines Rechnungslegungs- 
standards vorgegeben sind oder sich als geeignet zur Erfüllung der Berichts- 
zwecke erwiesen haben, ’?! jedoch keiner gesetzlichen Ermittlungsgrundlage un- 
terliegen. Während die Ermittlung eines im Geschäftsbericht zu veröffentli- 
chenden Gewinns oder Verlustes vom Gesetzgeber durch das HGB vorgegeben 
ist, liegt eine derartige Vorgabe beispielsweise für die Berechnung des Auf- 
tragsbestands nicht vor. Vielmehr ergibt sich das Verständnis, um was es sich 
bei der Kennzahl ,,Auftragsbestand“ handelt, aus der Definition dieser Größe 
durch die Fachabteilung, die diese Kennzahl nutzt. Um die Aktionen und damit 
die fachliche Funktionalität eines Berichtsservices zu spezifizieren ist — sofern 
vorhanden — auf bereits existierende Vorgehensweisen bzw. Berechnungs- 
vorschriften zurückzugreifen, die dokumentieren, wie sich Kennzahlen ermit- 
teln lassen bzw. zu ermitteln sind. 

Dieser Abschnitt führt auf, welche Schritte notwendig sind, um Berichtsser- 
vices, die infolge der Top-down-Analyse als Servicekandidaten identifiziert 
wurden, unter Einbezug einer dokumentierten Vorgehensweise fachlich gestal- 
tet werden können. Zur fachlichen Servicegestaltung sind fünf sequenziell aus- 
zuführende Schritte durchzuführen, die im Folgenden vorgestellt werden.722 


Schritt 1: Identifikation möglicher Vorgehensweisen 
Zu Beginn der fachlichen Servicegestaltung ist die Ausgangssituation zu ermit- 
teln, was Aufschluss darüber geben soll, ob für eine Aktivität bereits eine Vor- 


789 Mit Hilfe einer Bewertungsfunktion, die auch als Entscheidungsregel oder Präferenz- 
funktional bezeichnet wird, lassen sich die Präferenzen eines Entscheidungsträgers ab- 
bilden. Bewertungsfunktionen werden zur Unterstützung von Entscheidungen einge- 
setzt. Vgl. Wemers (2008), S. 25. 

790 Vgl. Berbner et al. (2005), S. 271. 

791 Vgl. Abschnitt 2.1.3. 


792 Vgl. Winkler (2007), S. 261 ff. 
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gehensweise dokumentiert ist. Die Identifikation möglicher Vorgehensweisen 
sowie alle weiteren in diesem Abschnitt vorgestellten Schritte sind für jede aus 
dem Berichtsprozessmodell heraus identifizierte Aktivität durchzuführen. In 
diesem Zusammenhang lassen sich drei Fälle unterscheiden. 

Liegt keine dokumentierte Vorgehensweise vor (Fall 1), muss eine entspre- 
chende Vorgehensweise für die fachliche Funktionalität der betrachteten Aktion 
erstellt werden (Zustand 1.1).793 Eine derartige Konstellation liegt etwa dann 
vor, wenn eine Kennzahl berichtet werden soll, die weder eine gesetzliche 
Grundlage hat noch jemals in der Unternehmung für die Zwecke der Unterneh- 
mungssteuerung erhoben wurde. In diesem Fall ist eine Vorgehensweise zu er- 
arbeiten und für die fachliche Servicegestaltung zu nutzen. 

Kann auf eine dokumentierte Vorgehensweise zurückgegriffen werden (Fall 
2), lässt sich diese zur fachlichen Gestaltung der Aktion übernehmen (Zustand 
1.2). Dieser Fall ist z. B. dann gegeben, wenn Jahresabschlussinformationen er- 
stellt werden müssen. Ein anderes Beispiel einer dokumentierten Vorgehens- 
weise ist die Ermittlung des ROI als Spitzenkennzahl eines Kennzahlen- 
baums.?94 

Letztlich kann ein Zustand gegeben sein (Fall 3), bei dem mehrere Vorge- 
hensweisen zur Verfügung stehen (Zustand 1.3). In diesem Fall ist in einem 
nächsten Schritt zu entscheiden, welche Vorgehensweise im Hinblick auf das 
jeweilige Anwendungsszenario der Aktion geeignet erscheint. Eine derartige 
Konstellation liegt beispielsweise dann vor, wenn eine zu berichtende Kennzahl 
(wie der Auftragsbestand) von verschiedenen Fachbereichen ohne explizite Er- 
läuterung unterschiedlich gedeutet wird.’95 Eine unterschiedliche Deutung wirkt 
sich wiederum auf die Berechnung der Kennzahl aus, ebenso wie auf die Inter- 
pretation der Ergebnisse. Für den Vertrieb ist es z. B. wichtig zu wissen, wie 
viele Aufträge insgesamt getätigt wurden (Kundenauftragsbestand), während 
die Produktion ihre Planung darauf ausrichtet, wie viele Aufträge sich gerade an 
den Maschinen befinden oder noch anstehen (Produktionsauftragsbestand). 


Schritt 2: Bestimmung sich ausschließender Voraussetzungen 

Von den oben genannten drei Ausgangssituationen bzw. Fällen ist die zuletzt 
genannte Konstellation (Zustand 1.3) für das weitere Vorgehen von übergeord- 
neter Bedeutung, da sich aus dieser weitere Schritte für die fachliche Gestaltung 
der Berichtsservices ergeben. Der weitere Verlauf zur fachlichen Servicegestal- 
tung wird dabei von zwei wesentlichen Zuständen beeinflusst. 


793 Im Folgenden steht die zweite Zahl nach dem Punkt für die Ausprägung des jeweiligen 
Zustands, während die Zahl vor den Punkt informiert, bei welchem Schritt zur fachli- 
chen Servicegestaltung der jeweilige Zustand auftritt. 

794 Vgl. Abschnitt 5.2.2.2.2.1. 


795 Vgl. Lehmann/Ellerau (1997), S. 84. 
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Der erste Zustand ist dadurch charakterisiert, dass die zur Verfügung stehen- 
den Vorgehensweisen verschiedene Voraussetzungen beinhalten, die sich ge- 
genseitig ausschließen (Zustand 1.3.1). In diesem Fall ist keine Auswahl der 
Vorgehensweisen erforderlich, da für die jeweils vorliegenden Voraussetzungen 
immer nur eine Vorgehensweise zur Durchführung geeignet ist. 

Bei der zweiten Alternative schließen sich die vorliegenden Voraussetzungen 
zur Anwendung der Vorgehensweisen nicht aus (Zustand 1.3.2). Dies hat zur 
Konsequenz, dass sich alle zur Verfügung stehenden Vorgehensweisen poten- 
ziell in Form eines Services in einer Unternehmung realisieren lassen. Da im 
Gegensatz zum ersten Fall bei der zweiten Variante (Zustand 1.3.2) mehrere 
Vorgehensweisen für den zugrunde liegenden Anwendungsfall in Frage kom- 
men, erfordert nur der zweite Fall eine detaillierte Betrachtung. 


Schritt 3: Bestimmung einer effizienten Vorgehensweise 

Zu untersuchen ist im Folgenden, welche Vorgehensweise für den gegebenen 
Anwendungsfall am besten geeignet ist. Zur Unterstützung einer derartigen Be- 
trachtung lässt sich das Effizienzkriterium verwenden.’96 Eine Vorgehensweise 
ist dabei effizient, wenn sie im Vergleich zu einer alternativen Vorgehensweise 
nicht schlechter abschneidet. Auf diese Weise lässt sich ein Ausschluss ineffi- 
zienter Vorgehensweisen durchführen. Um die Eignung der jeweiligen Vorge- 
hensweise zu bewerten, müssen geeignete Evaluationskriterien verwendet wer- 
den. Die zur Anwendung kommenden Kriterien müssen dabei insbesondere die 
fachlichen Eigenschaften der Berichtsservices berücksichtigen. Hierfür lassen 
sich folgende Kriterien identifizieren: 


Grad der Genauigkeit 

Der Grad der Genauigkeit eines zu ermittelnden Werts hat unmittelbaren Ein- 
fluss auf die Dauer der Ausführung einer Aktion. Lautet die Forderung bei- 
spielsweise, eine Kennzahl mit mehreren Nachkommastellen zu berechnen, sind 
höhere Antwortzeiten beim Aufruf des betreffenden Dienstes zu erwarten. 


Grad der Korrektheit 

Bei der Bedingung „Grad der Korrektheit‘ geht es um die Wahrscheinlichkeit, 
dass das von einem Berichtsservice ermittelte Ergebnis widerspruchsfrei ist und 
den tatsächlichen Wahrheitsgehalt widerspiegelt. Sind hohe Ansprüche an die 
Korrektheit eines Ergebnisses gegeben, ist zu überprüfen, ob und inwieweit 


796 Zum Effizienzkriterium vgl. Werners (2008), S. 27. 
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Korrektheits- bzw. Plausibilitätsprüfungen in den betreffenden Dienst einge- 
bunden werden müssen. ’9? 


Grad der Objektivität 

Diese Bedingung fokussiert die semantische Dimension des von einem Be- 
richtsservice berechneten Ergebnisses. Ein objektives Ergebnis liegt vor, wenn 
es sich eindeutig interpretieren lässt. Folglich ist in diesem Zusammenhang zu 
prüfen, ob bei der Verarbeitung der Geschäfts- und Finanzinformationen in ei- 
ner Aktion, eine XBRL-Taxonomie vorgeschaltet werden muss, die gewährleis- 
tet, dass nur diejenigen Informationen, denen im Vorfeld XBRL-Elemente zu- 
gewiesen wurden, sowohl als Input- als auch als Outputwerte Gegenstand einer 
dokumentierten Vorgehensweise sein können. 


Grad der Aktualität 

Der „Grad der Aktualität“ stellt ebenfalls eine wichtige Bedingung zur Auswahl 
einer geeigneten Vorgehensweise dar. Durch diese Bedingung wird ermittelt, 
wie hoch der Aktualitätsgrad der Inputinformationen sein muss, die für die Aus- 
führung der betrachteten Aktion als Eingabeparameter notwendig sind. 

Nach Anwendung des Effizienzkriteriums können sich für den Zustand 1.3.2 
zwei Folgezustände ergeben. Zum einen lässt sich eine dominante Vorgehens- 
weise ermitteln, die im Vergleich zu den Alternativen mindestens in einem Be- 
wertungskriterium besser abschneidet, während sie hinsichtlich der anderen 
Bewertungskriterien mindestens als gleichwertig eingestuft werden kann (Zu- 
stand 1.3.2.1). Zum anderen ist der Fall denkbar, dass sich nach Anwendung des 
Effizienzkriteriums keine dominante Vorgehensweise ermitteln lässt (Zustand 
1.3.2.2). Abbildung 45 fasst die Schritte 1 bis 3 zusammen. 


797 Derartige Plausibilitätsprüfungen spielen insbesondere bei der Durchführung von ETL- 
Prozessen eine große Rolle. Hierzu werden entsprechende Plausibilitätsroutinen ver- 
wendet, um möglichst frühzeitig Fehler bei der Aufbereitung der Daten festzustellen, die 
ansonsten erst zum Ende eines ETL-Prozesses, der je nach DWH-Anwendung über 


mehrere Minuten bis zu Stunden dauern kann, auffallen würden. 
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Liegt eine 
Vorgehens- 
weise vor? 


Ja 
(Zustand 1.2) 


Mehrere 
(Zustand 1.3) 


Nein 
(Zustand 1.1) 


Schließen sich die 
Voraussetzungen 
aus? 


Ja Nein 
(Zustand 1.3.1) (Zustand 1.3.2) 


Liegt eine effiziente 
Vorgehensweise 
vor? 


Ja Nein 
(Zustand 1.3.2.1) (Zustand 1.3.2.2) 


Abbildung 45: Übersicht der Schritte 1 bis 3 bei der fachlichen Servicegestaltung 


Schritt 4: Einbindung zusätzlicher Auswahllogiken 

Um im Rahmen der angestrebten Servicenutzung bei mehreren nicht dominier- 
ten Vorgehensweisen eine eindeutige Auswahl der Vorgehensweise zu ermögli- 
chen, sind zusätzliche Bedingungen in den Prozess zur Auswahl der jeweiligen 
Aktion zu integrieren. Derartige Bedingungen bzw. Auswahllogiken bedürfen 
geeigneter Kriterien, anhand derer sich die Selektion der Aktionen beurteilen 
lässt. 

Eine eindeutige Auswahl einer Vorgehensweise lässt sich gewährleisten, 
wenn die möglichen Vorgehensweisen in eine Ordnung gebracht werden. Zu 
diesem Zweck lassen sich die in Schritt 3 erarbeiteten fachlichen Kriterien he- 
ranziehen. Zusätzlich ist eine Priorisierung der angeführten Bewertungskriterien 
vorzunehmen, um zu gewährleisten, dass bei der Ausführung eines Services die- 
jenige Vorgehensweise zur Anwendung kommt, die das am höchsten priorisier- 


te fachliche Evaluationskriterium am besten erfüllt. Dieses Kriterium kann je 
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nach Einsatzzweck des Berichtsservices vor seiner Nutzung flexibel definiert 
werden. 


Schritt 5: Anpassung der Aktivitätsdiagramme 

Nachdem die Identifikation und die Auswahl geeigneter Vorgehensweisen ab- 
geschlossen sind, müssen im nächsten Schritt die bestehenden Aktivitätsdia- 
gramme angepasst werden. Eine Anpassung wird durchgeführt, indem die exis- 
tierenden Aktivitäten durch die „neuen“ Aktionen, denen jetzt eine Vorgehens- 
weise zugeordnet ist, ersetzt werden. Dies trifft auf die Aktivitäten mit dem Zu- 
stand 1.2, 1.3.1, 1.3.2.1 und 1.3.2.2 zu. 

Nachdem die neuen Aktvitäten ins Aktivitätsdiagramm überführt wurden, er- 
folgt eine erneute Überprüfung der bereits vorgenommenen Serviceidenti- 
fikation. Zu prüfen ist, ob die neuen Aktivitäten, die die bisherigen Aktionen er- 
setzt haben, zu einem Service gekapselt oder als separate Dienste ausgeführt 
werden sollen. Zur Beantwortung dieser Frage lässt sich die in Abschnitt 
5.2.2.2.1 präsentierte Vorgehensweise heranziehen. Dabei ist auch bei den neu- 
en Aktionen zu beachten, dass alle Aktivitäten, die gemeinsam auftreten, zu ei- 
nem Service zusammengefasst werden können. 

Eine Besonderheit ergibt sich bei der Identifikation von Services, denen meh- 
rere nicht dominierte Vorgehensweisen zugrunde liegen (Zustand 1.3.2.2). In 
diesem Zusammenhang ist darauf hinzuweisen, dass es nicht erforderlich ist, für 
jede Vorgehensweise einen eigenen Service zu entwickeln. Stattdessen stellt die 
Auswahllogik, die in diesem Service implementiert werden muss, sicher, wel- 
che Vorgehensweise bei der Ausführung des jeweiligen Services anzuwenden 
ist, so dass alle Vorgehensweisen in diesem Service implementiert werden kön- 
nen. 


5.3 Zusammenfassung und Würdigung des Vorgehensmodells 


Die Ausführungen dieses Kapitels hatten zum Ziel, ein Vorgehensmodell zu 
präsentieren, das sich zur konzeptionellen Gestaltung von SOBP eignet. Ausge- 
hend von der Vorstellung und Bewertung verschiedener Vorgehensstrategien 
zur Gestaltung Serviceorientierter Anwendungen wurden mit dem Meet-in-the- 
middle-Ansatz hierbei eine Strategie identifiziert, die sich zur konzeptionellen 
Gestaltung von SOBP grundsätzlich einsetzen lässt. Kennzeichnend für diese 
Vorgehensweise ist, dass sie mit der Berichtsprozessanalyse (Abschnitt 5.2.1) 
gemäß der Top-down-Vorgehensweise beginnt. Im Rahmen der berichtspro- 
zessmodellbasierten Serviceidentifikation (Abschnitt 5.2.2) erfolgt eine Erwei- 
terung der prozessorientierten Top-down-Vorgehensweise um die Bottom-up- 
Sicht. Als letzter Schritt ist die fachliche Berichtsservicegestaltung durchzufüh- 
ren (Abschnitt 5.2.3). 


Alexander Pastwa - 978-3-631-75488-7 
Downloaded from PubFactory at 01/11/2019 04:20:29AM 
via free access 


192 Zusammenfassung und Würdigung des Vorgehensmodells 


Im Vergleich zu alternativen Vorgehensweisen zeichnet sich der in diesem 
Kapitel präsentierte Ansatz dadurch aus, dass bei der konzeptionellen Gestal- 
tung von SOBP nicht nur methodische Aspekte berücksichtigt werden, die die 
prozessmodellorientierte sowie fachliche Identifikation und Gestaltung der Be- 
richtsservices betreffen, sondern zusätzlich Gesichtspunkte aufgegriffen wer- 
den, die aktuell im Kontext der Governance Serviceorientierter Anwendungen 
diskutiert werden.’?® Zu nennen ist in diesem Zusammenhang vor allem die 
Einbeziehung einer Lebenszyklusbetrachtung der Berichtsservices sowie die In- 
tegration eines Vorgehens zur Beurteilung der Dienstgüteeigenschaften.’9 

Die Einbindung einer Lebenszyklusbetrachtung sowie einer Methodik zur 
Bewertung der Dienstgüte der Services ermöglicht es, bei der konzeptionellen 
Gestaltung von Berichtsservices Einfluss auf die Anzahl und damit Pflege der 
in einem Serviceverzeichnis registrierten Dienste zu nehmen. Angesichts der 
Vielzahl der von einer Unternehmung betriebenen Berichtsanwendungen, In- 
formationsflüsse und somit potenziell in Frage kommenden Berichtsservices 
stellt die Pflege des Serviceverzeichnisses eine wichtige Herausforderung dar. 
Hierbei bietet die frühzeitige Prüfung der Potenziale der Nutzung unterneh- 
mungsexterner Services die Möglichkeit, einerseits aufwendige Eigenentwick- 
lungen zu verringern und andererseits einen Mehrwert bei der Informationsver- 
sorgung der Entscheidungsträger durch die Bereitstellung zusätzlicher Informa- 
tionen zu schaffen. 

Ferner lässt sich durch diese Instrumente gewährleisten, dass die Berichtsser- 
vices in der von den Nutzern geforderten Qualität ausgeführt werden. Da sich 
Berichtsprozesse und die damit verbundene effiziente und effektive Bereitstel- 
lung verlässlicher Geschäfts- und Finanzinformationen unmittelbar auf die Leis- 
tungsfähigkeit der Unternehmungssteuerung auswirken, ist die Einhaltung der 
Qualitätskriterien sowohl bei der Nutzung unternehmungsexterner Services als 
auch bei der Gestaltung neuer (interner) Berichtsservices umso mehr von Be- 
deutung. Mit Blick auf die aktuelle SOA-Literatur findet dieser Aspekt bei der 
Gestaltung Serviceorientierter Geschäftsprozesse bisher eine nur untergeordnete 
Rolle. 

Um zu gewährleisten, dass die zu gestaltenden SOBP dem Informationsbe- 
darf der Berichtsempfänger genügen, wurde mit dem Ordnungsrahmen zur Ziel- 
bestimmung von SOBP ein Schema präsentiert, das alle wichtigen Gestaltungs- 
parameter eines SOBP aufführt.300 Ein weiterer Vorteil des in diesem Kapitel 
präsentierten Vorgehensmodells ist in der Erweiterung der prozessmodellbasier- 
ten Vorgehensweise durch eine Bottom-up-gestützte Serviceidentifikation zu 


798 Eine Zusammenstellung verschiedener Methoden zur Konzeption Serviceorientierter 
Anwendungen präsentiert Offermann (2008), S. 463. 
799 Siehe hierzu die Abschnitte 5.2.1.3 und 5.2.3.4. 


800 Vgl. Abschnitt 5.2.1.1. 
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sehen. Auf diese Weise lässt sich gewährleisten, dass die von den Berichtsan- 
wendungen in vielfacher Ausprägung zur Verfügung gestellten Funktionen bei 
der konzeptionellen Gestaltung einer SOBP berücksichtigt werden und als po- 
tenzielle Berichtsservices bzw. Berichtsservicekandidaten in Frage kommen. 

Wird das in diesem Kapitel präsentierte Vorgehen zur konzeptionellen Ges- 
taltung von SOBP verfolgt, hat dies zur Konsequenz, dass im Rahmen der Be- 
richtsprozessanalyse alle zur Verfügung stehenden Prozessmodelle betrachtet 
werden müssen. Folglich sind nicht nur die fachlichen, sondern auch die techni- 
schen Prozessmodelle bereits implementierter Berichtsprozesse bei der Be- 
richtsprozessmodellanalyse einzubeziehen. Vor dem Hintergrund, dass Be- 
richtsprozessmodelle als Kommunikationsinstrument von den bei der SOBP- 
Gestaltung beteiligten Fachabteilungen und Softwareentwickler genutzt werden, 
kann das Problem auftreten, dass unterschiedliche Prozessmodelle als Kommu- 
nikationsgrundlage zur Verfügung stehen, die zu einem uneinheitlichen Pro- 
zessverständnis führen. Der Grund hierfür liegt darin, dass die fachliche und 
technische Modellierung von Prozessen i. d. R. entkoppelt voneinander durch- 
geführt werden, so dass eine durchgängige Modellierung von der fachlichen bis 
zur technischen Ebene erschwert wird bzw. ausbleibt.8°! 

Als Folge einer inkonsistenten Überführung der fachlichen Anforderungen 
der Services in die zum Einsatz kommenden IS lässt sich daher eine Modellie- 
rungs- sowie Dokumentationslücke identifizieren, die dadurch auftritt, dass Än- 
derungen in den fachlichen Prozessmodellen meist nicht mit den technischen 
Prozessmodellen synchronisiert werden. Diese von THOMAS/LEYKING/DREIFUS 
als Top-down-Problem bezeichnete Herausforderung wirkt sich nicht auf den 
Entwurf, sondern auch auf den Betrieb einer SOA aus.3% Gleichzeitig lässt sich 
das Problem erkennen, dass notwendige Änderungen an den von einer Unter- 
nehmung betriebenen IS nicht oder nicht vollständig in den fachlichen Pro- 
zessmodellen dokumentiert werden. Hier kann von einem Bottom-up-Problem 
gesprochen werden. 

Die von den Autoren angeführten Probleme lassen sich beheben, indem zu 
den in Abschnitt 5.2.1.2 aufgeführten Modellierungsmethoden alternative Nota- 
tionen zur Prozessmodellierung eingesetzt werden, die sich als Kommunikati- 
onsinstrument zwischen den bei der SOBP-Entwicklung beteiligten Akteuren 
nutzen lassen. Einen geeigneten und derzeit viel diskutierten Ansatz zur Verrin- 
gerung sowohl der Modellierungs- als auch der Dokumentationslücke liefert die 
Business-Process-Modeling-Notation (BPMN). 

Mit Hilfe der BPMN lässt sich ein fachliches Prozessmodell in ein fachlich- 
technisches Anwendungsmodell transformieren, das der Synchronisation und 


801 Vgl. Thomas/Leyking/Dreifus (2007), S. 37f. 


802 Vgl. Thomas/Leyking/Dreifus (2007), S. 38. 
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Integration der fachlichen und technischen Beschreibungsebene dient.8% Die 
BPMN stellt geeignete Sprachkonstrukte zur Verfügung, mit der das Grundge- 
rüst für den Ablauf des Prozesses definiert werden kann.84 Als Ausgangspunkt 
dient die Ablauflogik, die in das fachliche Prozessmodell eingebettet ist. Die 
Erweiterung des fachlichen Prozessmodells erfolgt durch die Einbeziehung 
technischer Details zur Prozessausführung.3% Bei der Modellierung des fach- 
lich-technischen Anwendungsmodells bedient sich die BPMN einer grafischen 
Darstellung der Prozesse und soll so dem Analysten, dem technischen Entwick- 
ler und dem Manager als gemeinsame Kommunikationsplattform dienen.306 
Damit repräsentiert die BPMN-Notation das Bindeglied zwischen dem Ge- 
schäftsprozessdesign und der Prozessimplementierung, wobei sie sich unabhän- 
gig von der späteren technischen Umsetzung bzw. Implementierung verwenden 
lässt. 


803 Vgl. Thomas/Leyking/Dreifus (2007), S. 38. 

804 Die BPMN wurde von der BUSINESS PROCESS MANAGEMENT INITIATIVE (BPMI) im Jahr 
2002 entwickelt und 2006 von der OBJECT MANAGEMENT GROUP (OMG) als Standard 
aufgenommen. 

805 Vgl. Thomas/Leyking/Dreifus (2007), S. 41. 


806 Vgl. Object Management Group (2006), S. 1. 
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6 Zusammenfassung und Resümee 


In diesem Kapitel werden die zentralen Ergebnisse der vorliegenden Arbeit zu- 
sammengefasst. Hierzu führt Abschnitt 6.1 den Aufbau sowie die wichtigsten 
Erkenntnisse der jeweiligen Kapitel auf. Abschnitt 6.2 diskutiert die Potenziale 
des in dieser Arbeit präsentierten Architektur- und Vorgehensmodells, die sich 
für die Reduzierung der Problemfelder des Berichtswesens ergeben. Abschnitt 
6.3 widmet sich einem Ausblick sowie weiterem Forschungsbedarf. 


6.1 Allgemeine Zusammenfassung 


Das Ergebnis dieser Arbeit ist ein Architektur- und Vorgehensmodell, das zur 
konzeptionellen Gestaltung von Berichtsprozessen auf Basis einer SOA und 
XBRL zum Einsatz kommen kann. 

Die Ausführungen von Kapitel 2 hatten zum Ziel, mit der Prozessorientierung 
des betrieblichen Berichtswesens ein betriebswirtschaftliches Anwendungsfeld 
zu präsentieren, das vor dem Hintergrund einiger Problemfelder Verbesserungs- 
potenziale bietet. Die Problemfelder verhindern sowohl eine effektive als auch 
effiziente Verarbeitung der im Rahmen des Berichtswesens anfallenden Ge- 
schäfts- und Finanzinformationen. Als zusammenfassendes Ergebnis der Aus- 
führungen dieses Kapitels wurde das Berichtswesen einer Unternehmung als 
Gesamtheit aller Personen, Prozesse und IS aufgefasst, die zur Erzeugung, Auf- 
bereitung, Übermittlung und Auswertung von formalisierten Berichten beitra- 
gen. Als Kernprozesse wurden die Informationsbeschaffung, Berichtserstellung, 
Berichtsdistribution und Berichtsaufnahme identifiziert. 

Aus der Perspektive der Wirtschaftsinformatik stellt sich die Frage, welche 
Konzepte und Technologien sich zur Lösung oder Reduzierung betriebs- 
wirtschaftlicher Probleme einsetzen lassen. Mit dem Konzept einer SOA liegt 
ein in Wissenschaft und Praxis aktuell viel diskutierter Ansatz vor. Kapitel 3 
hatte zum Ziel, aus den Beiträgen des Themenbereichs SOA ein integriertes 
SOA-Verständnis abzuleiten. Als Ergebnis ließ sich folgende Definition ermit- 
teln: „Unter einer SOA wird ein abstraktes Architekturkonzept aufgefasst, bei 
dem wiederverwendbare Softwarekomponenten, die bestimmten Designprinzi- 
pien unterliegen und eine gezielte Funktion erfüllen, zur Unterstützung einer in- 
tegrierten Informationsverarbeitung zum Einsatz kommen und insbesondere zur 
Flexibilisierung und/oder Automatisierung von Geschäftsprozessen beitragen 
sollen.“ 

Zusammenfassend ist festzuhalten, dass es sich bei SOA um ein ganzheitli- 
ches Architekturkonzept zur Gestaltung und Integration von IS handelt, das das 
Ziel verfolgt, eine integrierte Informationsverarbeitung zu ermöglichen. Kenn- 
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zeichnend für SOA ist, dass bei diesem Architekturkonzept nicht die Orientie- 
rung an den Organisationseinheiten sowie an den von diesen betriebenen mono- 
lithischen, heterogenen IS im Vordergrund steht, sondern die Nutzung kleiner, 
zeitlich stabiler Prozess- und Funktionsbausteine favorisiert wird.8°7 Die Bau- 
steine werden innerhalb einer SOA als lose gekoppelte, standardisierte (Soft- 
ware-)Services bzw. (Software-)Dienste angeboten, die sich zu einem funktio- 
nal erweiterbaren IS kombinieren lassen. 

Damit verspricht der Betrieb einer SOA, eine agile Applikationslandschaft zu 
realisieren, die an unternehmungsindividuelle Geschäftsanforderungen ange- 
passt werden kann und sich im Vergleich zu alternativen Integrationsansätzen 
durch ein höheres Maß an Flexibilität und Geschwindigkeit auszeichnet.308 Mit 
Blick auf die fachlichen Nutzenpotenziale erweist sich das sowohl von der Wis- 
senschaft als auch von der Praxis vorgebrachte Versprechen, applikations- 
und/oder unternehmungsübergreifende Geschäftsprozesse durch die Verwen- 
dung orchestrierter Services zu flexibilisieren und/oder automatisieren, als 
wichtiger Treiber für das Interesse an SOA. Im Gegensatz zu monolithischen 
Anwendungen stellt der Ansatz einer SOA damit in Aussicht, prozessorientierte 
Anwendungen zu realisieren, die sich nicht isoliert voneinander betreiben las- 
sen, sondern sich zum Ausführungszeitpunkt auf Basis dynamischer Services 
zusammensetzen.30° Vor diesem Hintergrund und der festzustellenden Defizite 
bei der Ausführung von Berichtsprozessen stellt SOA einen interessanten An- 
satz für die Zwecke des Berichtswesens dar. 

Kapitel 4 widmete sich der Vorstellung eines Architekturmodells, das für die 
Gestaltung von SOBP zum Einsatz kommen kann. Hierzu war es erforderlich, 
den SOBP-Begriff zu konkretisieren. Die dieser Arbeit zugrunde liegende 
SOBP-Definition lautet: „Unter einem SOBP wird ein Berichtsprozess verstan- 
den, bei dem die Aktivitäten und Teilprozesse der Kernprozesse Informations- 
beschaffung, Berichtserstellung, Berichtsdistribution und Berichtsaufnahme mit 
Hilfe von Berichtsservices implementiert werden, die dem Serviceverständnis 
einer SOA sowie den zugrunde liegenden Designprinzipien der Serviceorientie- 
rung folgen.“ Als Ergebnis ausgewerteter Vorschläge wurde zunächst ein Archi- 
tekturmodell präsentiert, das sich zur Gestaltung bzw. Einführung einer SOA 
einsetzen lässt. Im Anschluss erfolgte eine Erweiterung des Architekturmodells, 
die zum Ziel hat, eine stärkere semantische Verarbeitung von Geschäfts- und 
Finanzinformationen zu ermöglichen. Die Erweiterung basiert auf dem XBRL- 
Standard. 


807 Vgl. Schelp (2007), S. 147. 

808 Dass die Serviceorientierung einen größeren Beitrag zur Agilität einer Unternehmung 
als einzelne Technologien leistet, ließ sich in verschiedenen Fallstudien belegen. Vgl. 
Schelp/Winter (2007), S. 44. 


809 Vgl. Winkler (2007), S. 258. 
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Die Ausführungen des Kapitels 5 fokussierten ein Vorgehensmodell zur kon- 
zeptionellen Gestaltung von SOBP. Aufbauend auf einer Diskussion bestehen- 
der Vorgehensstrategien, die generell für die Gestaltung Serviceorientierter 
Anwendungen in Frage kommen, wurde der Meet-in-the-middle-Ansatz, der 
sowohl Aspekte des Top-down- als auch des Bottom-up-Vorgehens integriert, 
als geeigneter Ansatz identifiziert. 


6.2 Zusammenfassung der Nutzenpotenziale des Architektur- und Vor- 
gehensmodells zur Reduzierung der Defizite beim Reporting 


Die folgenden Ausführungen fassen die zentralen Erkenntnisse dieser Arbeit 
zusammen im Hinblick auf die Möglichkeit, die in Abschnitt 2.3 diskutierten 
Defizite bei der Ausführung der Kernprozesse des Berichtswesens zu reduzie- 
ren. In diesem Zusammenhang werden auch die Nutzenpotenziale erörtert, die 
sich aus dem um XBRL erweiterten SOA-Architekturmodell (Kapitel 4) sowie 
dem Vorgehensmodell zur konzeptionellen Gestaltung von SOBP (Kapitel 5) 
identifizieren lassen. Nachdem in Abschnitt 6.2.1 die Nutzenpotenziale zur Re- 
duzierung zweckbezogener Defizite diskutiert werden, widmet sich Abschnitt 
6.2.2 den Nutzenpotenzialen zur Minderung inhaltsbezogener Defizite. Die 
Ausführungen des Abschnitts 6.2.3 richten sich auf die Vermeidung syntaxbe- 
zogener Defizite, die beim Reporting auftreten können. 


6.2.1 Nutzenpotenziale zur Vermeidung zweckbezogener Defizite 


Die im Architekturmodell von Kapitel 4 dargestellte Möglichkeit, Anwendungs- 
systeme auf Basis von Services und XBRL zu koppeln, birgt nicht nur Potenzia- 
le, die sich auf die Effizienz der Informationsverarbeitung im betrieblichen Be- 
richtswesen auswirken.8!0 Die Vorteile, die sich aus den beschriebenen Mög- 
lichkeiten zur semantischen sowie datenkonsistenten Verarbeitung der Ge- 
schäfts- und Finanzinformationen ergeben, haben unmittelbaren Einfluss auf die 
fachlichen Nutzungsmöglichkeiten einer SOA für die Zwecke des Berichtswe- 
sens, die sich wiederum auf die Effektivität des Reportings auswirken. 

Der integrierte Einsatz von Services und XBRL eröffnet Möglichkeiten, die 
Empfängerorientierung und die Aktualität der Informationsversorgung im be- 
trieblichen Berichtswesen zu steigern. Die Gestaltung geeigneter, auf den In- 
formationsbedarf der Berichtsempfänger zugeschnittener Services, die ausge- 
wählte Daten der XBRL-Instanzdokumente verarbeiten, ermöglicht es, eine 
empfängerorientierte Informationsversorgung zu implementieren. Indem Be- 
richtsservices realisiert werden können, die eine bestimmte Sicht auf einen Da- 


810 Siehe hierzu die Ausführungen in Abschnitt 6.2.3. 
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tenbestand abbilden, lässt sich gewährleisten, dass nur diejenigen Informationen 
eines Instanzdokuments einem Berichtsempfänger zur Verfügung gestellt wer- 
den, die für diesen eine Relevanz besitzen. 

Eine stärkere Empfängerorientierung lässt sich zudem durch die verschiede- 
nen Publikationsmöglichkeiten realisieren, die der Einsatz von XBRL bietet. 
Durch die Anwendung von Cascading Style Sheets (CSS) oder der Extensible 
Stylesheet Language (XSL) lassen sich XBRL-Berichte nach den Anforderun- 
gen der Berichtsempfänger layouten und in verschiedenen Formaten und Prä- 
sentationsvarianten beispielsweise auf der Web-Site einer Unternehmung oder 
im Intranet zum Download anbieten.?!! Darüber hinaus lassen sich die Informa- 
tionen dieser Dokumente durch den Einsatz z. B. von Web Services, die ausge- 
wählte Informationen der veröffentlichten Dokumente abfragen, weiterverarbei- 
ten. 


6.2.2 Nutzenpotenziale zur Minderung inhaltsbezogener Defizite 


Mit Blick auf die in Abschnitt 2.3.2 thematisierten inhaltsbezogenen Problem- 
felder, die eine effektive Ausführung der Berichtsprozesse verhindern, ist zu 
konstatieren, dass insbesondere der Einsatz von XBRL Nutzenpotenziale zur 
Reduzierung dieser Problemfelder bietet. 

Eine wichtige Aufgabe erfüllen in diesem Zusammenhang die XBRL- 
Taxonomien, die in dem in Kapitel 4 präsentierten Architekturmodell in einer 
separaten Schicht angeordnet sind. Als technische Referenz für die zum Einsatz 
kommenden Instanzdokumente gewährleisten die Taxonomien, dass sich nur 
vordefinierte Elemente bzw. Konzepte mit vereinbarten Attributen als Informa- 
tionseinheiten innerhalb einer SOBP nutzen lassen. Da es sich bei den Taxono- 
mien um eine normierte Begriffs- und Strukturvorschrift handelt, erhalten die 
Geschäfts- und Finanzinformationen, die in den Instanzdokumenten mit Hilfe 
der Taxonomieelemente beschrieben werden, eine Bedeutung. Auf diese Weise 
lassen sich die in einem Instanzdokument präsentierten Informationen durch 
den Einsatz entsprechender Berichtsservices nicht nur in weitere Berichtsan- 
wendungen transferieren, sondern auch von menschlichen Nutzern interpretie- 
ren. 

Im Zusammenhang mit der Nutzung von XBRL ist hervorzuheben, dass es 
sich bei diesem XML-Dialekt um einen ausschließlich technischen Standard 
handelt, dessen Ziel es ist, über ein von allen Nutzern geteiltes sowie eindeuti- 
ges Verständnis zu den Informationsobjekten des Berichtswesens Geschäfts- 


811 Vel. Nutz/StrauB (2002), S. 452. 
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und Finanzinformationen automatisiert zu verarbeiten.8!2 Folglich geht es bei 
XBRL um die Abbildung bestehender Rechnungslegungsvorschriften und kei- 
neswegs um die Erstellung neuer inhaltlicher Rechnungslegungsstandards.313 
Damit besitzt XBRL nicht das Potenzial, Probleme zu lösen, die sich beispiels- 
weise aus der Interpretation sowie aus dem Vergleich von Bilanzwerten ver- 
schiedener Rechnungslegungsstandards ergeben. 

Bei einem Blick auf die vergangenen sowie aktuellen Aktivitäten zur Etablie- 
rung von XBRL wird deutlich, dass dieser Standard zur Verarbeitung von Ge- 
schäfts- und Finanzinformationen eine große Bedeutung hat.3!% Nach WILLIS/ 
HANNON ist in den kommenden Jahren eine stärkere Einbettung einer Funktio- 
nalität zur Verarbeitung von XBRL-Daten in die bestehenden Softwareprodukte 
zu erwarten.8!5 Eine zunehmende Nutzung von XBRL, die teilweise auf gesetz- 
lichen Vorgaben beruht, ist gegenwärtig an ausländischen Börsenplätzen sowie 
Börsenaufsichten wie der Shanghai Stock Exchange (SSE), der Comisiön Naci- 
onal del Mercado de Valores (CNMV), dem Committee of European Banking 
Supervisors (CEBS) oder der amerikanischen Bankenaufsicht festzustellen.316 
Im internationalen Vergleich ist die Zahl der in Deutschland publizierten Jah- 
resabschlüsse auf Basis von XBRL bis zum gegenwärtigen Zeitpunkt als gering 
einzustufen. Als Pioniere in diesem Bereich gelten die Unternehmungen Soft- 
ware AG, Fraport und Microsoft, die ausgewählte Geschäftszahlen im XBRL- 
Format an der Deutschen Börse veröffentlicht haben.3!7 


6.2.3 Nutzenpotenziale zur Reduzierung syntaxbezogener Defizite 


Der Einsatz von Berichtsservices, die gekapselte Funktionen zur Verfügung 
stellen, bietet die Möglichkeit, Geschäfts- und Finanzinformationen über Appli- 
kationsgrenzen hinweg zu verarbeiten. Auf diese Weise lassen sich syntaktisch 
bedingte Problemfelder reduzieren, die oftmals dadurch entstehen, dass diese 
Informationen bei der Ausführung der Berichtsprozesse zwischen verschiede- 


812 Vgl. Baars (2005), S. 194. Dass es sich bei XBRL um ein technisches Framework han- 
delt, wird auch bei RAMIN/KESSELMEYER/OTT deutlich. Vgl. Ramin/Kesselmeyer/Ott 
(2006a), S. 181. 

813 Vgl. Meyer-Pries/Gröner (2002), S. 45. 

814 Hannon präsentiert hierzu einen Überblick zu den in den vergangenen Jahren initiierten 
Aktivitäten zur Weiterentwicklung sowie zur Verbreitung von XBRL. Vgl. Hannon 
(2004), S. 58. 

815 Vgl. Willis/Hannon (2005), S. 59. 

816 Vgl. Ramin/Kesselmeyer/Ott (2006a), S. 180f. Einen Überblick über weitere XBRL- 
Projekte liefert auch Hannon (2006), S. 59. 

817 Vgl. Gruppe Deutsche Börse (2009). Als weitere Pioniere lassen sich auch die Unter- 
nehmungen MORGAN STANLEY und REUTERS nennen. Vgl. Kranich/Schmitz (2003), 


S. 79. 
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nen IS ausgetauscht und von verschiedenen Anwendern bearbeitet werden müs- 
sen, die für die Analyse und Darstellung der Berichte eine Reihe von Software- 
Tools und Dateiformate nutzen.318 Dass sich Geschäfts- und Finanzinformatio- 
nen über Systemgrenzen hinweg durch den Einsatz entsprechender Berichtsser- 
vices verarbeiten lassen, wird durch das Prinzip der „Abstraktion von der Imp- 
lementierungslogik“ gewährleistet.319 

Da gemäß des Prinzips der „Abstraktion von der Implementierungslogik“ le- 
diglich die Serviceschnittstelle für die Servicenutzung ausreicht, besteht die 
Möglichkeit, gekapselte Dienste nicht nur zum Ablauf verschiedener Ge- 
schäftsprozesse schnell und ohne zusätzlichen Aufwand nutzen zu können,820 
sondern mit selbigen Vorteilen für die Gestaltung einer SOBP verwenden zu 
können. Kostenreduzierende Effekte ergeben sich dabei infolge einer einfachen 
Anpassung der Berichtsprozesse,82! da Änderungen in den zu unterstützenden 
Prozessen oder auch Teilprozessen durch eine Neu- bzw. Rekombination der 
Services und nicht durch eine Neuentwicklung oder einer vollständigen Anpas- 
sung der bestehenden Funktionalität der Dienste durchgeführt werden kön- 
nen.822 Als Beispiel lässt sich der Einsatz eines Berichtsservice zur Währungs- 
umrechnung nennen, der aufgrund seines Funktionsumfangs in vielen Berichts- 
prozessen verwendet werden kann, bei denen zur Ermittlung eines bestimmten 
Ergebnisses eine Währungskonvertierung erforderlich ist. 

Die beim Betrieb einer SOA anvisierten Einsparungspotenziale, die sich aus 
einer hohen Wiederverwendung der Berichtsservices ergeben, sind insbesonde- 
re dann gegeben, wenn die Dienste nicht nur von einem großen Nutzerkreis, 
sondern auch in möglichst vielen Berichtsprozessen zum Einsatz kommen. 
Hierzu wurde in Kapitel 5 ein Vorgehensmodell präsentiert, das zum Ziel hat, 
Berichtsservices mit einem hohen Wiederverwendungsgrad konzeptionell zu 
gestalten. 

Der Einsatz von Berichtsservices, die aus den Aktivitäten eines zugrunde lie- 
genden fachlichen Berichtsprozessmodells gebildet und mit Hilfe einer 
Workflow-Engine orchestriert werden, birgt zudem Potenziale, eine applikati- 
ons- und/oder unternehmungsübergreifende SOBP zu flexibilisieren und/oder 
zu automatisieren. Medienbrüche, fehlerhafte Eingaben sowie unproduktive Da- 
tentransformationen lassen sich auf diese Weise vermeiden. 


818 Vgl. Abschnitt 2.3.3. 

819 Vgl. hierzu Abschnitte 3.3.2.1. 

820 Vgl. hierzu Winkler (2007), S. 258. 

821 Wie SCHELP/WINTER in diesem Zusammenhang feststellen, erfordert eine flexible Orga- 
nisation sowie Reorganisation der zu unterstützenden Geschäftsprozesse auf Basis mo- 
dularer Services generell, dass die Applikationen ressourcenschonend integriert und 
entkoppelt werden können. Vgl. Schelp/Winter (2007), S. 44. 


822 Vgl. Schelp/Stutz (2007), S. 67. 
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Dabei können verschiedene Operationen Bestandteil eines automatisierten 
und flexibel anpassbaren Berichtsprozesses sein.823 Berichtsservices können 
z. B. sequentiell entlang einer vorgegebenen Anweisungskette ausgeführt wer- 
den. In diesem Zusammenhang eröffnet die Nutzung von Services zahlreiche 
Einsatzszenarien, bei denen formulierte Datenabfragen kaskadierend weitere 
Datenabfragen (d. h. weitere Services) entlang einer Prozesskette auslösen. Ne- 
ben reinen Datenabfragen ist auch die Abbildung komplexer Prozesse vorstell- 
bar, bei denen beispielsweise Services eingebunden werden, die ein automati- 
sches Benchmarking oder ein Kundenrating in einem SOBP integrieren.824 Eine 
derartige Abarbeitung sequentiell angeordneter Schritte lässt sich erweitern, in- 
dem bedingte Ausdrücke aufgenommen werden. Hierbei lassen sich alle aus den 
Programmiersprachen bekannten Ausprägungen einer Bedingung (wie einfache, 
zweifache oder mehrfache Alternativen) zur Abbildung einer entsprechenden 
Prozesslogik einsetzen. 

Über den Einsatz von Diensten lassen sich zudem Berichtsprozesse ausfüh- 
ren, die zu einem im Vorfeld festgelegten Zeitpunkt ausgelöst werden. In die- 
sem Zusammenhang ist das Beispiel einer Servicegestützten Bereitstellung von 
Informationen zu nennen, die nach vordefinierten Zeitintervallen automatisiert 
in ein Ziel-IS eingelesen werden. In Abhängigkeit des spezifischen Anwen- 
dungsbereichs wäre hier eine minütliche, stündliche, tagesaktuelle, wöchentli- 
che oder auch monatliche Informationsbereitstellung denkbar. Eine derartige 
Anwendung von Services, die sich zu einem zeitgesteuerten Prozessservice or- 
chestrieren lassen, würde damit Aufgaben bzw. Funktionen übernehmen, die im 
Kontext eines DWH-Einsatzes klassischerweise von ETL-Systemen erfüllt wer- 
den.825 

Genauso wie bei der zeitgesteuerten Auslösung eines Berichtsprozesses kann 
eine Prozessautomatisierung auch durch das Eintreten eines vordefinierten Er- 
eignisses bzw. Events erfolgen. Eine derartige Funktionalität wird im Kontext 
von Datenbanksystemen auch als Trigger bezeichnet. Als Beispiel für einen er- 
eignisgesteuerten Prozess ist ein Service denkbar, der nach der Änderung eines 
Wertes eines bestimmten Attributs einen weiteren Dienst auslöst. Durch diesen 
wiederum lässt sich eine bestimmte Abfrage beispielsweise auf die Relation ei- 
nes weiteren Datenbanksystems ausführen, bevor die hieraus resultierende Er- 
gebnismenge schließlich in eine separate Tabelle geschrieben wird. 


823 Vgl. Melzer et al. (2007), S. 310. 
824 Siehe hierzu das Beispiel bei Buxmann/Hess/Widjaja (2007), S. 1316ff. 


825 Siehe hierzu die Abschnitte 2.2.1.1 und 5.2.1.2.1. 
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6.3 Ausblick und weiterer Forschungsbedarf 


Mit Blick auf die zum Teil euphorische Erwartungshaltung, die seitens einiger 
Autoren im Zusammenhang mit dem Betrieb einer SOA geäußert wurde,826 ver- 
spricht der Einsatz von Web Services generell Nutzenpotenziale für die kosten- 
günstige Integration von Anwendungen bei gleichzeitiger Unterstützung unter- 
nehmungs- und/oder applikationsübergreifender Geschaftsprozesse.82”? Da- 
durch, dass sie eine klar definierte Aufgabe erfüllen, bieten Web Services die 
Möglichkeit, die von ihnen angebotene Leistung zu zentralisieren und auszula- 
gern.828 Damit eignen sich Web Services auch zur Ausführung von Berichtsser- 
vices, die die Verarbeitung von Geschäfts- und Finanzinformationen fokussie- 
ren und von einer großen Anwenderzahl in Anspruch genommen werden kön- 
nen. Im Vergleich zu konkurrierenden Ansätzen bieten Web Services den Vor- 
teil einer schnelleren und kostengünstigeren Nutzung.82? Damit besitzt dieser 
Standard insbesondere eine Relevanz für kleine und mittlere Unternehmungen 
(KMU), die vor dem Hintergrund einer geringeren Ressourcenausstattung an 
kostengünstigen Integrationslösungen interessiert sind.830 

ALT/HEUTSCHVÖSTERLE prophezeien in diesem Zusammenhang, dass Web 
Services insbesondere für unternehmungsinterne Zwecke sowie bei bereits be- 
stehenden Unternehmungspartnerschaften eingesetzt werden.83! Damit besitzt 
diese Technologie Nutzungspotenziale für die Gestaltung von Berichtsprozes- 
sen von und zwischen Unternehmungen, die beispielsweise innerhalb einer 
Konzernstruktur miteinander verbunden sind. 

Im Ergebnis ist zu konstatieren, dass es bisher nur in wenigen Ausnahmefäl- 
len gelungen ist, eine unternehmungsweite SOA zu implementieren, innerhalb 
dieser sämtliche unternehmungsinterne und -übergreifende Geschäftsprozesse 


826 Vgl. Abschnitt 3.2. 

827  IssInG prophezeit in diesem Zusammenhang, dass sich die Realisierung von Web Servi- 
ce-basierten Architekturen zu einem Mainstream entwickeln wird, wobei nach Auffas- 
sung des Autors positive Auswirkungen auf die Effizienz einer SOA in belegbarer Wei- 
se durch den Einsatz von Investitionsrechnungen zu erwarten sind. Vgl. Issing (2003), 
S. 30. Der Autor lässt in diesem Zusammenhang allerdings offen, auf welche Weise eine 
Quantifizierung der Effizienzvorteile — z. B. ausgedrückt in Form eines positiven Kapi- 
talwerts — durchgeführt werden kann. 

828 Vgl. Alt/Heutschi/Osterle (2003), S. 64. 

829 Vgl. Küster (2003), S. 6. 

830 Die Vorteile, die sich aus der Interoperabilität insbesondere für KMU ergeben, werden 
prägnant von KÜSTER zusammengefasst, der in diesem Zusammenhang schreibt: „Web- 
Services bringen Interoperabilität für die Massen“. 


81 Vgl. Alt/Heutschi/Osterle (2003), S. 69. 
Alexander Pastwa - 978-3-631-75488-7 


Downloaded from PubFactory at 01/11/2019 04:20:29AM 
via free access 


Zusammenfassung und Resümee 203 


auf Basis verknüpfter Services automatisiert und/oder flexibilisiert sind.832 
Stattdessen wurden in der Vergangenheit Projekte mit dem Ziel initiiert, einzel- 
ne Anwendungsbereiche bzw. Geschäftsprozesse einer Unternehmung durch die 
Nutzung ausgewählter Services zu unterstützten, so dass die daraus resultieren- 
den softwaretechnischen Lösungen den Charakter einer Serviceorientierten 
Anwendung oder Plattform aufweisen.333 Als federführende Branchen, die sich 
in den vergangenen Jahren intensiv mit der Einführung von SOA beschäftigt 
haben, sind der Finanz- und der Logistiksektor zu nennen.834 

Der Einschätzung von RIEKS zufolge ist generell die augenblickliche Nut- 
zung von SOA mit der zögerlichen Anwendung des Internets Mitte der 90er 
Jahre vergleichbar.335 Ein Blick auf die Vielzahl aktueller Beiträge und initiier- 
ter Integrationsprojekte verdeutlicht, dass das Interesse an SOA nach wie vor 
ungebrochen ist, so dass SOA den befürchteten Status eines neuen Schlagwor- 
tes in der Wirtschaftsinformatik hinter sich gelassen hat.836 Gleichzeitig ist aber 
auch zu bemerken, dass das Wissen zur umfassenden Einführung einer SOA 
insbesondere in den Fachabteilungen vieler Unternehmungen defizitär ist.837 
Vor dem Hintergrund der nach wie vor anhaltenden Aktualität im Zusammen- 
hang mit der Entwicklung und Nutzung von Services sind daher weitere For- 
schungsanstrengungen zu erwarten, so dass SOA auch in den kommenden Jah- 
ren die Diskussion um geeignete Konzepte zur IT-Unterstützung einer integrier- 
ten Informationsverarbeitung beherrschen wird.838 Folglich ist für die weitere 


832 Auf die bisher geringe Anzahl von SOA-Implementierungen und den damit verbunde- 
nen geringen Erfahrungsschatz mit SOA verweisen auch BUXMANN/HESS/WIDJAJA. 
Vgl. Buxmann/Hess/Widjaja (2007), S. 1316. Nach STREIBICH liegt in Deutschland der 
derzeitige Anteil von SOA-Projekten im Verhältnis zur Gesamtheit aller Integrations- 
projekte auf einem niedrigen Niveau von ca. 15 %. Vgl. Streibich (2008), S. 73. 

833 Vgl. hierzu die Beispiele einer Serviceorientierten Anwendung bei Hinkelmann/ 
Thönssen/Probst (2005), S. 356ff.; Modjo Kamneng et al. (2007), S. 289ff.; Theling/ 
Janssen/Loos (2006), S. 403ff.; Thomas/Leyking/Dreifus (2007), S. 39ff.; Luh- 
mann/Meister/Wulff (2007), S. 344ff.; Hanhart/Legner/Österle (2008), S. 478ff.; Kubli 
et al. (2008), S. 544ff.; Schelp/Aier (2008), S. 535ff. 

834 Vgl. Streibich (2008), S. 73. Prominente Beispiele von Unternehmungen, die mit SOA 
positive Erfahrungen gesammelt haben, sind die DEUTSCHE POST und CREDIT SUISSE. 
Vgl. Esch et al. (2008), S. 93. 

835 Vgl. Rieks (2006), S. 6. 

836 Der Einschätzung des Analystenhauses GARTNER zufolge werden bis 2010 rund 65 % 
der großen Unternehmungen über 35 % ihres Anwendungsportfolios mit Hilfe einer 
SOA realisieren. Vgl. Thomas/Leyking/Dreifus (2007), S. 44. 

837 Vgl. Streibich (2008), S. 73. 

838 Mit Blick auf den GARTNER HYPE CYCLE - eine von der Unternehmung GARTNER ver- 
öffentlichte Kurve, die für die kommenden zehn Jahre die wichtigsten Technologien 
prognostiziert, die bei der Anwendungsentwicklung zum Einsatz kommen — wird SOA 


für die kommenden zwei bis fünf Jahren hetaustagen,. N gl. Piitter Qt 008), S. 2 
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Akzeptanz des SOA-Konzepts zu fordern, dass die Nutzungspotenziale Servi- 
ceorientierter Anwendungen und ihre Implikationen für die Geschäftsmodelle 
von Softwareanbietern und -nachfragern in den jeweiligen Arbeiten, die sich 
mit diesem Aspekt beschäftigen, besser ausgearbeitet werden.839 

Ein weiteres wichtiges Forschungsfeld umfasst die Weiterentwicklung und 
den Einsatz von SOA-Governance-Technologien, um die Einhaltung von SLA 
zu gewährleisten, den Lebenszyklus von Services zu steuern oder die Verwal- 
tung der Benutzerprofile in einer SOA zu ermöglichen.34 Die Vorteile, die eine 
Nutzung von Berichtsservices zur Flexibilisierung und/oder Automatisierung 
von SOBP bieten, können sich nämlich umkehren, wenn der Aufwand zur Be- 
wältigung der daraus resultierenden Servicekomplexität die Potenziale über- 
steigt, die sich durch die Flexibilisierung und/oder Automatisierung einer derar- 
tigen Lieferkette eröffnen. Die Gefahr einer steigenden Servicekomplexität ist 
insbesondere vor dem Hintergrund nachvollziehbar, wenn davon ausgegangen 
wird, dass die bereits im Einsatz befindlichen Services im Fall einer notwendig 
gewordenen Anpassung entweder von der SOA-betreibenden Unternehmung 
nachträglich geändert oder durch neue Dienste, die von einem unternehmungs- 
externen Anbieter stammen, ersetzt werden. 

Die zu bewältigende Komplexität resultiert insbesondere aus den Abhängig- 
keiten zwischen den Diensten, wie sie im Rahmen der Orchestrierung von Ser- 
vices angestrebt werden. Wird ein Service in seinem Funktionsumfang modifi- 
ziert, sind die daraus resultierenden Auswirkungen auch an den abhängigen 
Diensten zu berücksichtigen.3*! Bestehen vielfältige, in Teilen gar netzwerkar- 
tige Verknüpfungen zwischen den Services, sind von der SOA-betreibenden 
Unternehmung entsprechende Aufwendungen zu leisten, um eine Koordination 
sowie Überwachung der Servicenutzung zu ermöglichen. 

Der Änderungsaufwand entsteht dadurch, dass die Serviceimplementierung 
im Fall einer notwendig gewordenen Änderung modifiziert werden muss. Sind 
von diesem Service weitere Dienste betroffen, so sind auch die von diesen er- 
brachten Funktionen zu überdenken und gegebenenfalls anzupassen. Ein wich- 
tiger Kostentreiber bei der Änderung der Funktionalität eines Dienstes ist in 
diesem Zusammenhang in der Anpassung der Servicebeschreibungen zu identi- 
fizieren, deren Änderungsaufwand nach NEWCOMER/LOMOW im Vergleich zu 
den Aufwendungen, die bei der technischen Modifizierung eines Service ent- 
stehen, als höher einzustufen ist.842 Der bei der Anpassung einer Servicebe- 
schreibung resultierende höhere Aufwand hängt insbesondere davon ab, inwie- 


839 Dass dieser Zustand aktuell nicht gegeben ist, beklagen Nüttgens/Dirik (2008), S. 31. 
840 Vgl. hierzu Pütter (2008), S. 2. 
841 Vgl. Schelp (2007), S. 146. 


842 Vgl. Newcomer/Lomow (2005), S. 77. 
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weit der zu ändernde Service als Leistungserbringer für weitere Dienste 
dient.343 

Der in der Literatur vorgeschlagene Ausweg, Varianten des von der Ände- 
rung betroffenen Services zu gestalten, birgt die Gefahr, dass die daraus resul- 
tierende hohe Anzahl der Dienste zum einen zu höheren Wartungskosten, zum 
anderen zu einer geringeren Wiederverwendungsrate der Services führen kann. 
Dieses Problem tritt insbesondere dann zutage, wenn neue Dienste oder neue 
Varianten bestehender Dienste in einen bereits existierenden Servicebestand 
aufgenommen werden. 

Generell ist zu konstatieren, dass die Definition der Dienste i. d. R. sich als 
keine triviale Aufgabe erweist. SCHELP/STUTZ zufolge liegt der Aufwand, der 
unternommen werden muss, um einen Dienst mit einem hohen Wieder- 
verwendungsgrad zu gestalten, im Vergleich zu Services, die sich durch einen 
niedrigeren Wiederverwendungsgrad auszeichnen, um mehr als das Dreifache 
hdher.844 Vor diesem Hintergrund bietet der in Kapitel 5 vorgeschlagene Ansatz 
eine methodische Vorgehensweise, Berichtsservices mit dem Ziel einer hohen 
Wiederverwendbarkeit konzeptionell zu gestalten. 

Ferner wird über die Akzeptanz einer SOA entscheiden, ob insbesondere für 
unternehmungskritische Anwendungen, bei denen beispielsweise vertrauliche 
Daten auf Basis orchestrierter Dienste verarbeitet werden, eine sichere Service- 
nutzung gewährleistet werden kann.845 Diese Überlegungen sind insbesondere 
für SOBP anzustellen, bei denen Berichtsservices zum Einsatz kommen, die als 
Web Services implementiert werden und damit allen Sicherheitsbedenken einer 
web-gestützten Informationsverarbeitung unterliegen. 

Als Letztes ist zu bemerken, dass in dieser Arbeit der Themenbereich Servi- 
ceorientiertes Prozesscontrolling (SOPC) nicht thematisiert wurde. In diesem 
Zusammenhang ist zu konstatieren, dass mit der Berücksichtigung eines Bewer- 
tungsverfahrens zur Auswahl der zum Einsatz kommenden Berichtsservices das 
Fundament für ein SOPC gelegt wurde. Das Controlling Serviceorientierter 
Prozesse ist eine wichtige Voraussetzung für ihre Gestaltung. In der Erarbeitung 
geeigneter Instrumente zur Abschätzung der Wirtschaftlichkeit der mit Hilfe ei- 
ner SOA ausgeführten Prozesse ist weiterer Forschungsbedarf zu identifizie- 
ren.346 


843 Vgl. Newcomer/Lomow (2005), S. 77. Zur Beherrschung der Abhängigkeiten zwischen 
den Diensten und den damit verbunden Kosten schlagen die Autoren den Einsatz forma- 
ler Mechanismen zur Versionierung der Serviceverträge vor. 

844 Vgl. Schelp/Stutz (2007), S. 67. 

845 Auf die Notwendigkeit, Sicherheitsprobleme bei der Nachrichtenübertragung zwischen 
Services zu lösen, verweisen z. B. Beimborn/Mintert/Weitzel (2002), S. 278. 

846 Eine auch für die Zwecke des Controllings von Berichtsservices geeignete Konzeption 


liefert vom Brocke (2008), S. 55ff. 
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Trotz der Vielzahl der publizierten Beiträge ist ein Grund für die derzeit zu 
beobachtende Zurückhaltung bei der Implementierung von XBRL-gestützten 
Anwendungen in der Unkenntnis hinsichtlich der Funktionsweise und der Nut- 
zungsmöglichkeiten von XBRL auszumachen.847 Uber eine produktive Nutzung 
von XBRL entscheiden neben einem erforderlichen Fachwissen zu XBRL 
selbstverständlich Kosten-Nutzen-Überlegungen einer Unternehmung. Der 
Aufwand zur Implementierung einer XBRL-basierten Informationskette be- 
stimmt sich insbesondere aus der Realisierung der Mapping-Prozesse zwischen 
den Objekten der Daten liefernden sowie Daten empfangenden Systeme und 
den Elementen einer Taxonomie. Als weiterer Kostentreiber fällt die fortwäh- 
rende Anpassung der XBRL-Taxonomien aufgrund von Änderungen in den 
Rechnungslegungsstandards ins Gewicht. Auf der Nutzenseite stehen diesen 
Aspekten die stakeholderspezifische Bereitstellung von Geschäfts- und Finanz- 
informationen, die schnellere und verlässlichere Informationsversorgung sowie 
die Möglichkeit zum Online-Reporting entgegen. 

Zusammen mit dem Einsatz auf den Informationsbedarf der Berichts- 
empfänger zugeschnittener Berichtsservices bietet der Einsatz von XBRL Po- 
tenziale zur Ausführung effizienter und effektiver Berichtsprozesse. Das in die- 
ser Arbeit präsentierte Architektur- und Vorgehensmodell zeigt auf, wie sich 
XBRL und das SOA-Architekturkonzept für die konzeptionelle Gestaltung von 
SOBP kombinieren lassen. 


847 Vgl. hierzu Meall (2007), S. 73. 
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